-
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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: digital: Bounds check NFC-A cascade depth in SDD response handlerThe NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3or 4 bytes to target->nfcid1 on each round, but the number of cascaderounds is controlled entirely by the peer device. The peer sets thecascade tag in the SDD_RES (deciding 3 vs 4 bytes) and thecascade-incomplete bit in the SEL_RES (deciding whether another roundfollows).ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 issized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driveractually enforces this. This means a malicious peer can keep thecascade running, writing past the heap-allocated nfc_target with eachround.Fix this by rejecting the response when the accumulated UID would exceedthe buffer.Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays")fixed similar missing checks against the same field on the NCI path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- wicked < 0.6.79-150700.3.3.1 (version in image is 0.6.78-150700.1.4).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12svm_copy_lbrs() always marks VMCB_LBR dirty in the destination VMCB.However, nested_svm_vmexit() uses it to copy LBRs to vmcb12, andclearing clean bits in vmcb12 is not architecturally defined.Move vmcb_mark_dirty() to callers and drop it for vmcb12.This also facilitates incoming refactoring that does not pass the entireVMCB to svm_copy_lbrs().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: Unknown.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-typing_extensions < 4.12.2-150400.3.17.1 (version in image is 4.9.0-150600.1.3).
-
Description: BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to version 0.28.1, when using a custom BuildKit frontend, the frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context. The issue has been fixed in v0.28.1. The vulnerability requires using an untrusted BuildKit frontend set with `#syntax` or `--build-arg BUILDKIT_SYNTAX`. Using these options with a well-known frontend image like `docker/dockerfile` is not affected.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user. Plugins that request exactly one privilege are also affected, because no comparison is performed at all. This issue has been patched in version 29.3.1.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ). This issue has been patched in version 29.3.1.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: reset op_nents when zerocopy page pin failsWhen iov_iter_get_pages2() fails in rds_message_zcopy_from_user(),the pinned pages are released with put_page(), andrm->data.op_mmp_znotifier is cleared. But we fail to properlyclear rm->data.op_nents.Later when rds_message_purge() is called from rds_sendmsg() thecleanup loop iterates over the incorrectly non zero number ofop_nents and frees them again.Fix this by properly resetting op_nents when it should be inrds_message_zcopy_from_user().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_tcpmss: check remaining length before reading optlenQuoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::NodeSet#[] (and its alias #slice) checked the requested index against the node set's bounds using a 32-bit-truncated copy of the index. A large negative index could pass the check and then be used at full width, reading outside the node set's storage. On CRuby this is an out-of-bounds read that typically crashes the process; on JRuby it is not memory-unsafe but returns an incorrect node. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, calling Document#encoding= with an invalid encoding (e.g., a non-string, or a string containing a null byte) raises an exception, but only after freeing the document's current encoding string without replacing it. The document is left referencing freed memory, so the next call to Document#encoding reads invalid memory, which can cause a segfault or leak freed bytes into a Ruby String. Affects the CRuby (libxml2) implementation only; JRuby is not affected. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
Description: XML::LibXML versions through 2.0210 for Perl read out-of-bounds heap memory when parsing XML node names containing truncated UTF-8 byte sequences.A node name ending in the middle of a multi byte UTF-8 sequence causes the parser to read past the end of the input string into adjacent heap memory.Any Perl process that passes attacker controlled strings to XML::LibXML's DOM node-name methods can reach this path on the default API. The likely consequence is a crash, causing denial of service.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- perl-XML-LibXML < 2.0132-150000.3.8.1 (version in image is 2.0132-150000.3.3.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).
-
Description: When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: ERB is a templating system for Ruby. Ruby 2.7.0 (before ERB 2.2.0 was published on rubygems.org) introduced an `@_init` instance variable guard in `ERB#result` and `ERB#run` to prevent code execution when an ERB object is reconstructed via `Marshal.load` (deserialization). However, three other public methods that also evaluate `@src` via `eval()` were not given the same guard: `ERB#def_method`, `ERB#def_module`, and `ERB#def_class`. An attacker who can trigger `Marshal.load` on untrusted data in a Ruby application that has `erb` loaded can use `ERB#def_module` (zero-arg, default parameters) as a code execution sink, bypassing the `@_init` protection entirely. ERB 4.0.3.1, 4.0.4.1, 6.0.1.1, and 6.0.4 patch the issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby > 0-0 (version in image is 2.5-1.21).
-
Description: Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @revoked.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SMP: force responder MITM requirements before building the pairing responsesmp_cmd_pairing_req() currently builds the pairing response from theinitiator auth_req before enforcing the local BT_SECURITY_HIGHrequirement. If the initiator omits SMP_AUTH_MITM, the response canalso omit it even though the local side still requires MITM.tk_request() then sees an auth value without SMP_AUTH_MITM and mayselect JUST_CFM, making method selection inconsistent with the pairingpolicy the responder already enforces.When the local side requires HIGH security, first verify that MITM canbe achieved from the IO capabilities and then force SMP_AUTH_MITM in theresponse in both rsp.auth_req and auth. This keeps the responder auth bitsand later method selection aligned.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT wantto intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and thehypercall is something other than one of the supported Hyper-V hypercalls.When all of the above conditions are met, KVM will intercept VMMCALL butnever forward it to L1, i.e. will let L2 make hypercalls as if it were L1.The TLFS says a whole lot of nothing about this scenario, so go with thearchitectural behavior, which says that VMMCALL #UDs if it's notintercepted.Opportunistically do a 2-for-1 stub trade by stub-ifying the new APIinstead of the helpers it uses. The last remaining "single" stub willsoon be dropped as well.[sean: rewrite changelog and comment, tag for stable, remove defunct stubs]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: fix for dma-fence safe access rulesCommit 506aa8b02a8d6 ("dma-fence: Add safe access helpers and documentthe rules") details the dma-fence safe access rules. The most commonculprit is that drm_sched_fence_get_timeline_name may race withgroup_free_queue.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsqlite3-0 < 3.53.2-150000.3.42.1 (version in image is 3.51.3-150000.3.39.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsqlite3-0 < 3.53.2-150000.3.42.1 (version in image is 3.51.3-150000.3.39.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- cifs-utils > 0-0 (version in image is 6.15-150400.3.18.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: HIDP: Fix possible UAFThis fixes the following trace caused by not dropping l2cap_connreference when user->remove callback is called:[ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00[ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy)[ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014[ 97.809947] Call Trace:[ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122)[ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808)[ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798)[ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1))[ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341)[ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2))[ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360)[ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285)[ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5))[ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752)[ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716)[ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691)[ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678)[ 97.810404] __fput (fs/file_table.c:470)[ 97.810430] task_work_run (kernel/task_work.c:235)[ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201)[ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5))[ 97.810527] do_exit (kernel/exit.c:972)[ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810574] ? __pfx_do_exit (kernel/exit.c:897)[ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6))[ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4))[ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1))[ 97.810721] do_group_exit (kernel/exit.c:1093)[ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1))[ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366)[ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810826] ? vfs_read (fs/read_write.c:555)[ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800)[ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555)[ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 97.810960] arch_do_signal_or_restart (arch/---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffersmc_rx_splice() allocates one smc_spd_priv per pipe_buffer and storesthe pointer in pipe_buffer.private. The pipe_buf_operations for thesebuffers used .get = generic_pipe_buf_get, which only increments the pagereference count when tee(2) duplicates a pipe buffer. The smc_spd_privpointer itself was not handled, so after tee() both the original and thecloned pipe_buffer share the same smc_spd_priv *.When both pipes are subsequently released, smc_rx_pipe_buf_release() iscalled twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), whichthen escalates to a NULL-pointer dereference and kernel panic viasmc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exceptionBeyond the memory-safety problem, duplicating an SMC splice buffer issemantically questionable: smc_rx_update_cons() would advance theconsumer cursor twice for the same data, corrupting receive-windowaccounting. A refcount on smc_spd_priv could fix the double-free, butthe cursor-accounting issue would still need to be addressed separately.The .get callback is invoked by both tee(2) and splice_pipe_to_pipe()for partial transfers; both will now return -EFAULT. Users who needto duplicate SMC socket data must use a copy-based read path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: fix use-after-free in encoder release pathThe fops_vcodec_release() function frees the context structure (ctx)without first cancelling any pending or running work in ctx->encode_work.This creates a race window where the workqueue handler (mtk_venc_worker)may still be accessing the context memory after it has been freed.Race condition: CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // waits for m2m job "done" mtk_venc_worker() v4l2_m2m_job_finish() // m2m job "done" // BUT worker still running! // post-job_finish access: other ctx dereferences // UAF if ctx already freed // returns (job "done") kfree(ctx) // ctx freedRoot cause: The v4l2_m2m_ctx_release() only waits for the m2m joblifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle.After v4l2_m2m_job_finish() is called, the m2m framework considersthe job complete and v4l2_m2m_ctx_release() returns, but the workerfunction continues executing and may still access ctx.The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work)The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctxfields even after calling v4l2_m2m_job_finish().This vulnerability was confirmed with KASAN by running an instrumentedtest module that widens the post-job_finish race window. KASAN detected: BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx).This ensures the workqueue handler is both cancelled (if pending) andsynchronized (waits for any running handler to complete) before thecontext is freed.Placement rationale: The fix is placed after v4l2_ctrl_handler_free()and before list_del_init(&ctx->list). At this point, all m2m operationsare done (v4l2_m2m_ctx_release() has returned), and we need to ensurethe workqueue is synchronized before removing ctx from the list andfreeing it.Note: The open error path does NOT need cancel_work_sync() becauseINIT_WORK() only initializes the work structure - it does not scheduleit. Work is only scheduled later during device_run() operations.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Limit PTP to a single pageCommit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256playback streams, but the additional pages are not used by the cardcorrectly. The CT20K2 hardware already has multiple VMEM_PTPALregisters, but using them separately would require refactoring theentire virtual memory allocation logic.ct_vm_map() always uses PTEs in vm->ptp[0].area regardless ofCT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). Whenaggregate memory allocations exceed this limit, ct_vm_map() tries toaccess beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7eRevert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_countremain unchanged.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: HVM guest I/O port accesses are subject to either emulation or at leasttranslation. Translations are managed by the device model (viaXEN_DOMCTL_ioport_mapping), and hence the linked list used may changedat any time. Traversal of those lists (while handling guest I/O portaccesses) therefore needs synchronizing with updates, which was missingso far.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- xen-libs < 4.20.3_06-150700.3.41.1 (version in image is 4.20.3_04-150700.3.36.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - fix DMA corruption on long hmac keysWhen a key longer than block size is supplied, it is copied and thenhashed into the real key. The memory allocated for the copy needs tobe rounded to DMA cache alignment, as otherwise the hashed key maycorrupt neighbouring memory.The rounding was performed, but never actually used for the allocation.Fix this by replacing kmemdup with kmalloc for a larger buffer,followed by memcpy.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: defer struct eventpoll free to RCU grace periodIn certain situations, ep_free() in eventpoll.c will kfree the epi->epeventpoll struct while it still being used by another concurrent thread.Defer the kfree() to an RCU callback to prevent UAF.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: strictly check for maximum number of actionsThe maximum number of flowtable hardware offload actions in IPv6 is:* ethernet mangling (4 payload actions, 2 for each ethernet address)* SNAT (4 payload actions)* DNAT (4 payload actions)* Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ.* Redirect (1 action)Which makes 17, while the maximum is 16. But act_ct supports for tunnelsactions too. Note that payload action operates at 32-bit word level, somangling an IPv6 address takes 4 payload actions.Update flow_action_entry_next() calls to check for the maximum number ofsupported actions.While at it, rise the maximum number of actions per flow from 16 to 24so this works fine with IPv6 setups.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - fix overflow on long hmac keysWhen a key longer than block size is supplied, it is copied and thenhashed into the real key. The memory allocated for the copy needs tobe rounded to DMA cache alignment, as otherwise the hashed key maycorrupt neighbouring memory.The copying is performed using kmemdup, however this leads to an overflow:reading more bytes (aligned_len - keylen) from the keylen source buffer.Fix this by replacing kmemdup with kmalloc, followed by memcpy.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: Fix thermal zone device registration error pathIf thermal_zone_device_register_with_trips() fails after registeringa thermal zone device, it needs to wait for the tz->removal completionlike thermal_zone_device_unregister(), in case user space has managedto take a reference to the thermal zone device's kobject, in which casethermal_release() may not be called by the error path itself and tz maybe freed prematurely.Add the missing wait_for_completion() call to the thermal zone deviceregistration error path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()In the drain loop, the local variable 'runtime' is reassigned to alinked stream's runtime (runtime = s->runtime at line 2157). Afterreleasing the stream lock at line 2169, the code accessesruntime->no_period_wakeup, runtime->rate, and runtime->buffer_size(lines 2170-2178) - all referencing the linked stream's runtime withoutany lock or refcount protecting its lifetime.A concurrent close() on the linked stream's fd triggerssnd_pcm_release_substream() -> snd_pcm_drop() -> pcm_release_private()-> snd_pcm_unlink() -> snd_pcm_detach_substream() -> kfree(runtime).No synchronization prevents kfree(runtime) from completing while thedrain path dereferences the stale pointer.Fix by caching the needed runtime fields (no_period_wakeup, rate,buffer_size) into local variables while still holding the stream lock,and using the cached values after the lock is released.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: fix integer overflow in run_unpack() volume boundary checkThe volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses rawaddition which can wrap around for large lcn and len values, bypassingthe validation. Use check_add_overflow() as is already done for theadjacent prev_lcn + dlcn and vcn64 + len checks added by commit3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()").Found by fuzzing with a source-patched harness (LibAFL + QEMU).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0530-150500.20.52.1 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base > 0-0 (version in image is 0.7.35-150700.11.5.2).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/dma-buf: fix UAF with retry loopRetry doesn't work here, since bo will be freed on error, leading toUAF. However, now that we do the alloc & init before the attach, we cannow combine this as one unit and have the init do the alloc for us. Thisshould make the retry safe.Reported by Sashiko.v2: Fix up the error unwind (CI)(cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetickvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), andaen_host_forward() index the GAIT by manually multiplying the indexwith sizeof(struct zpci_gaite).Since aift->gait is already a struct zpci_gaite pointer, thisdouble-scales the offset, accessing element aisb*16 instead of aisb.This causes out-of-bounds accesses when aisb >= 32 (withZPCI_NR_DEVICES=512)Fix by removing the erroneous sizeof multiplication.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: A flaw was found in binutils. A heap-buffer-overflow vulnerability exists when processing a specially crafted XCOFF (Extended Common Object File Format) object file during linking. A local attacker could trick a user into processing this malicious file, which could lead to arbitrary code execution, allowing the attacker to run unauthorized commands, or cause a denial of service, making the system unavailable.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: call ->free_folio() directly in folio_unmap_invalidate()We can only call filemap_free_folio() if we have a reference to (or hold alock on) the mapping. Otherwise, we've already removed the folio from themapping so it no longer pins the mapping and the mapping can be removed,causing a use-after-free when accessing mapping->a_ops.Follow the same pattern as __remove_mapping() and load the free_foliofunction pointer before dropping the lock on the mapping. That lets usmake filemap_free_folio() static as this was the only caller outsidefilemap.c.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
Description: SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: Unknown.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-typing_extensions < 4.12.2-150400.3.17.1 (version in image is 4.9.0-150600.1.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_userAfter commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list inhci_chan_del"), l2cap_conn_del() uses conn->lock to protect access toconn->users. However, l2cap_register_user() and l2cap_unregister_user()don't use conn->lock, creating a race condition where these functions canaccess conn->users and conn->hchan concurrently with l2cap_conn_del().This can lead to use-after-free and list corruption bugs, as reportedby syzbot.Fix this by changing l2cap_register_user() and l2cap_unregister_user()to use conn->lock instead of hci_dev_lock(), ensuring consistent lockingfor the l2cap_conn structure.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- bind-utils < 9.20.23-150700.3.25.1 (version in image is 9.20.21-150700.3.18.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix integer underflow in chain modeThe jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax isBUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit()decides to invoke jumbo_frm() based on skb->len (total length includingpage fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc);When a packet has a small linear portion (nopaged_len <= bmax) but alarge total length due to page fragments (skb->len > bmax), thesubtraction wraps as an unsigned integer, producing a huge len value(~0xFFFFxxxx). This causes the while (len != 0) loop to executehundreds of thousands of iterations, passing skb->data + bmax * ipointers far beyond the skb buffer to dma_map_single(). On IOMMU-lessSoCs (the typical deployment for stmmac), this maps arbitrary kernelmemory to the DMA engine, constituting a kernel memory disclosure andpotential memory corruption from hardware.Fix this by introducing a buf_len local variable clamped tomin(nopaged_len, bmax). Computing len = nopaged_len - buf_len is thenalways safe: it is zero when the linear portion fits within a singledescriptor, causing the while (len != 0) loop to be skipped naturally,and the fragment loop in stmmac_xmit() handles page fragments afterward.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSGThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrementsbc_ackers on every inbound group ACK, even when the same member hasalready acknowledged the current broadcast round.Because bc_ackers is a u16, a duplicate ACK received after the lastlegitimate ACK wraps the counter to 65535. Once wrapped,tipc_group_bc_cong() keeps reporting congestion and later groupbroadcasts on the affected socket stay blocked until the group isrecreated.Fix this by ignoring duplicate or stale ACKs before touching bc_acked orbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent andprevents the underflow path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to version 0.28.1, insufficient validation of Git URL fragment subdir components may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem. The issue has been fixed in version v0.28.1 The issue affects only builds that use Git URLs with a subpath component. As a workaround, avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh < 9.6p1-150600.6.42.1 (version in image is 9.6p1-150600.6.37.1).
-
Description: The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc < 2.38-150600.14.49.1 (version in image is 2.38-150600.14.46.1).
-
Description: Some shadow paging errors paths will switch the page-tables withoutupdating the currently running vCPU reference. This causes a mismatchbetween the loaded page-tables and the mapcache metadata which can leadto corruption of the mapcache.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- xen-libs < 4.20.3_06-150700.3.41.1 (version in image is 4.20.3_04-150700.3.36.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: validate bsscfg indices in IF eventsbrcmf_fweh_handle_if_event() validates the firmware-provided interfaceindex before it touches drvr->iflist[], but it still uses the rawbsscfgidx field as an array index without a matching range check.Reject IF events whose bsscfg index does not fit in drvr->iflist[]before indexing the interface array.[add missing wifi prefix]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-urllib3 < 2.0.7-150400.7.30.1 (version in image is 2.0.7-150400.7.27.1).
-
Description: Billy is an interface filesystem abstraction for Go. Prior to versions 5.9.0 and 6.0.0-alpha.1, multiple components may improperly handle crafted or malformed input, resulting in panics, infinite loops, uncontrolled recursion, or excessive resource consumption. These issues arise from insufficient validation and missing safety mechanisms such as cycle detection, recursion limits, or defensive handling of unexpected states when processing untrusted repository data and filesystem structures. This issue has been patched in versions 5.9.0 and 6.0.0-alpha.1.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl1_1 < 1.1.1w-150700.11.22.1 (version in image is 1.1.1w-150700.11.19.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- bind-utils < 9.20.23-150700.3.25.1 (version in image is 9.20.21-150700.3.18.1).
-
Description: Undefined behavior may result due to a race condition leading to a use-after-free violation. If BIND receives an incoming DNS message signed with SIG(0), it begins work to validate that signature. If, during that validation, the "recursive-clients" limit is reached (as would occur during a query flood), and that same DNS message is discarded per the limit, there is a brief window of time while the SIG(0) validation may attempt to read the now-discarded DNS message.This issue affects BIND 9 versions 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, and 9.20.9-S1 through 9.20.22-S1.BIND 9 versions 9.18.28 through 9.18.49 and 9.18.28-S1 through 9.18.49-S1 are NOT affected.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- bind-utils < 9.20.23-150700.3.25.1 (version in image is 9.20.21-150700.3.18.1).
-
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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- krb5 > 0-0 (version in image is 1.20.1-150600.11.14.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_eui64: reject invalid MAC header for all packets`eui64_mt6()` derives a modified EUI-64 from the Ethernet source addressand compares it with the low 64 bits of the IPv6 source address.The existing guard only rejects an invalid MAC header when`par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()`can still reach `eth_hdr(skb)` even when the MAC header is not valid.Fix this by removing the `par->fragoff != 0` condition so that packetswith an invalid MAC header are rejected before accessing `eth_hdr(skb)`.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libacl1 > 0-0 (version in image is 2.2.52-4.3.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libacl1 > 0-0 (version in image is 2.2.52-4.3.1).
-
Description: Moby is an open source container framework. In versions prior to 29.5.1 and in moby/moby v2 prior to v2.0.0-beta.14, when a compressed archive is uploaded to a container via `PUT /containers/{id}/archive` or piped through `docker cp -`, the daemon resolves decompression binaries (such as `xz` or `unpigz`) from the container's filesystem rather than the host's due to incorrect ordering of operations. A malicious container image containing a trojanized decompression binary can achieve arbitrary code execution with full daemon privileges, including host root UID and unrestricted capabilities, when a user uploads a compressed (xz or gzip) archive into that container. This issue is fixed in Docker Engine 29.5.1 and moby/moby v2.0.0-beta.14. Workarounds include only running containers from trusted images, using authorization plugins to restrict access to the `PUT /containers/{id}/archive` endpoint, and avoiding piping compressed archives into containers created from untrusted images
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()l2cap_ecred_data_rcv() reads the SDU length field from skb->data usingget_unaligned_le16() without first verifying that skb contains at leastL2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this readspast the valid data in the skb.The ERTM reassembly path correctly calls pskb_may_pull() before readingthe SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply thesame validation to the Enhanced Credit Based Flow Control data path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix off-by-8 bounds check in check_wsl_eas()The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EAname and value, but ea_data sits at offset sizeof(structsmb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp()later reads ea->ea_data[0..nlen-1] and the value bytes follow atea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1+ vlen. Isn't pointer math fun?The earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the8-byte header is in bounds, but since the last EA is placed within 8bytes of the end of the response, the name and value bytes are read pastthe end of iov.Fix this mess all up by using ea->ea_data as the base for the boundscheck.An "untrusted" server can use this to leak up to 8 bytes of kernel heapinto the EA name comparison and influence which WSL xattr the data isinterpreted as.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gzip > 0-0 (version in image is 1.10-150200.10.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix double free related to rereg_user_mrIf IB_MR_REREG_TRANS is set during rereg_user_mr, theumem will be released and a new one will be allocatedin irdma_rereg_mr_trans. If any step of irdma_rereg_mr_transfails after the new umem is allocated, it releases the umem,but does not set iwmr->region to NULL. The problem is thatthis failure is propagated to the user, who will then callibv_dereg_mr (as they should). Then, the dereg_mr path willsee a non-NULL umem and attempt to call ib_umem_release again.Fix this by setting iwmr->region to NULL after ib_umem_release.Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region")
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix in-place encryption corruption in SMB2_write()SMB2_write() places write payload in iov[1..n] as part of rq_iov.smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message()encrypts iov[1] in-place, replacing the original plaintext withciphertext. On a replayable error, the retry sends the same iov[1]which now contains ciphertext instead of the original data,resulting in corruption.The corruption is most likely to be observed when connections areunstable, as reconnects trigger write retries that re-send thealready-encrypted data.This affects SFU mknod, MF symlinks, etc. On kernels before6.10 (prior to the netfs conversion), sync writes also usedthis path and were similarly affected. The async write pathwasn't unaffected as it uses rq_iter which gets deep-copied.Fix by moving the write payload into rq_iter via iov_iter_kvec(),so smb3_init_transform_rq() deep-copies it before encryption.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix watch_id bounds checking in debug address watch v2The address watch clear code receives watch_id as an unsigned value(u32), but some helper functions were using a signed int and checkedbits by shifting with watch_id.If a very large watch_id is passed from userspace, it can be convertedto a negative value. This can cause invalid shifts and may accessmemory outside the watch_points array.drm/amdkfd: Fix watch_id bounds checking in debug address watch v2Fix this by checking that watch_id is within MAX_WATCH_ADDRESSES beforeusing it. Also use BIT(watch_id) to test and clear bits safely.This keeps the behavior unchanged for valid watch IDs and avoidsundefined behavior for invalid ones.Fixes the below:drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c:448kfd_dbg_trap_clear_dev_address_watch() error: buffer overflow'pdd->watch_points' 4 <= u32max user_rl='0-3,2147483648-u32max' uncappeddrivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c 433 int kfd_dbg_trap_clear_dev_address_watch(struct kfd_process_device *pdd, 434 uint32_t watch_id) 435 { 436 int r; 437 438 if (!kfd_dbg_owns_dev_watch_id(pdd, watch_id))kfd_dbg_owns_dev_watch_id() doesn't check for negative values so ifwatch_id is larger than INT_MAX it leads to a buffer overflow.(Negative shifts are undefined). 439 return -EINVAL; 440 441 if (!pdd->dev->kfd->shared_resources.enable_mes) { 442 r = debug_lock_and_unmap(pdd->dev->dqm); 443 if (r) 444 return r; 445 } 446 447 amdgpu_gfx_off_ctrl(pdd->dev->adev, false);--> 448 pdd->watch_points[watch_id] = pdd->dev->kfd2kgd->clear_address_watch( 449 pdd->dev->adev, 450 watch_id);v2: (as per, Jonathan Kim) - Add early watch_id >= MAX_WATCH_ADDRESSES validation in the set path to match the clear path. - Drop the redundant bounds check in kfd_dbg_owns_dev_watch_id().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: The CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.ECDH and ECDSA signing relying on this curve are not affected.The bug was fixed in v1.6.3 https://github.com/cloudflare/circl/releases/tag/v1.6.3 .
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recvmsg() unconditional requeueIf rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call atthe front of the recvmsg queue already has its mutex locked, it requeuesthe call - whether or not the call is already queued. The call may be onthe queue because MSG_PEEK was also passed and so the call was not dequeuedor because the I/O thread requeued it.The unconditional requeue may then corrupt the recvmsg queue, leading tothings like UAFs or refcount underruns.Fix this by only requeuing the call if it isn't already on the queue - andmoving it to the front if it is already queued. If we don't queue it, wehave to put the ref we obtained by dequeuing it.Also, MSG_PEEK doesn't dequeue the call so shouldn't callrxrpc_notify_socket() for the call if we didn't use up all the data on thequeue, so fix that also.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: Fix race condition in espintcp_close()This issue was discovered during a code audit.After cancel_work_sync() is called from espintcp_close(),espintcp_tx_work() can still be scheduled from paths such asthe Delayed ACK handler or ksoftirqd.As a result, the espintcp_tx_work() worker may dereference afreed espintcp ctx or sk.The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work);To prevent this race condition, cancel_work_sync() isreplaced with disable_work_sync().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Fix race condition in tls_sw_cancel_work_tx()This issue was discovered during a code audit.After cancel_delayed_work_sync() is called from tls_sk_proto_close(),tx_work_handler() can still be scheduled from paths such as theDelayed ACK handler or ksoftirqd.As a result, the tx_work_handler() worker may dereference a freedTLS object.The following is a simple race scenario: cpu0 cpu1tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0);To prevent this race condition, cancel_delayed_work_sync() isreplaced with disable_delayed_work_sync().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: cfm: Fix race condition in peer_mep deletionWhen a peer MEP is being deleted, cancel_delayed_work_sync() is calledon ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs insoftirq context under rcu_read_lock (without RTNL) and can re-scheduleccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()returning and kfree_rcu() being called.The following is a simple race scenario: cpu0 cpu1mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mepTo prevent this, cancel_delayed_work_sync() is replaced withdisable_delayed_work_sync() in both peer MEP deletion paths, sothat subsequent queue_delayed_work() calls from br_cfm_frame_rx()are silently rejected.The cc_peer_disable() helper retains cancel_delayed_work_sync()because it is also used for the CC enable/disable toggle path wherethe work must remain re-schedulable.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bpf: defer hook memory release until rcu readers are doneYiming Qian reports UaF when concurrent process is dumping hooks vianfnetlink_hooks:BUG: KASAN: slab-use-after-free in nfnl_hook_dump_one.isra.0+0xe71/0x10f0Read of size 8 at addr ffff888003edbf88 by task poc/79Call Trace: nfnl_hook_dump_one.isra.0+0xe71/0x10f0 netlink_dump+0x554/0x12b0 nfnl_hook_get+0x176/0x230 [..]Defer release until after concurrent readers have completed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: Fix double-free in teql_master_xmitWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset shouldbe called using the seq_lock to avoid racing with the datapath. Failureto do so may cause crashes like the following:[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)[ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318[ 238.029749][ T318][ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)[ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 238.029910][ T318] Call Trace:[ 238.029913][ T318] [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122)[ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)[ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139)[ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)...[ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139)[ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)[ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139)[ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231)[ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))[ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139)...[ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256)[ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)[ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)...[ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034)[ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)[ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)[ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)[ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)[ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)...[ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s:[ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58)[ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))[ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369)[ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)[ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))[ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713)[ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)[ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997)[ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)[ 238.081469][ T318][ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s:[ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58)[ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))[ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))[ 238.085900][ T318] __kasan_slab_free (mm/---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].smc_tcp_syn_recv_sock() is called in the TCP receive path(softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCPlistening socket). It reads sk_user_data to get the smc_sockpointer. However, when the SMC listen socket is being closedconcurrently, smc_close_active() sets clcsock->sk_user_datato NULL under sk_callback_lock, and then the smc_sock itselfcan be freed via sock_put() in smc_release().This leads to two issues:1) NULL pointer dereference: sk_user_data is NULL when accessed.2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.The race window looks like this (the syzkaller crash [1]triggers via the SYN cookie path: tcp_get_cookie_sock() ->smc_tcp_syn_recv_sock(), but the normal tcp_check_req() pathhas the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash!Note that the clcsock and smc_sock are two independent objectswith separate refcounts. TCP stack holds a reference on theclcsock, which keeps it alive, but this does NOT prevent thesmc_sock from being freed.Fix this by using RCU and refcount_inc_not_zero() to safelyaccess smc_sock. Since smc_tcp_syn_recv_sock() is called inthe TCP three-way handshake path, taking read_lock_bh onsk_callback_lock is too heavy and would not survive a SYNflood attack. Using rcu_read_lock() is much more lightweight.- Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock().- Use rcu_read_lock() to protect reading sk_user_data.- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.Note: smc_hs_congested() has a similar lockless read ofsk_user_data without rcu_read_lock(), but it only checks forNULL and accesses the global smc_hs_wq, never dereferencingany smc_sock field, so it is not affected.Reproducer was verified with mdelay injection and smc_run,the issue no longer occurs with this patch applied.[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for thenetlink dump callback ctnetlink_exp_ct_dump_table(), but drops theconntrack reference immediately after netlink_dump_start(). When thedump spans multiple rounds, the second recvmsg() triggers the dumpcallback which dereferences the now-freed conntrack via nfct_help(ct),leading to a use-after-free on ct->ext.The bug is that the netlink_dump_control has no .start or .donecallbacks to manage the conntrack reference across dump rounds. Otherdump functions in the same file (e.g. ctnetlink_get_conntrack) properlyuse .start/.done callbacks for this purpose.Fix this by adding .start and .done callbacks that hold and release theconntrack reference for the duration of the dump, and move thenfct_help() call after the cb->args[0] early-return check in the dumpcallback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fdThe /proc/fs/nfs/exports proc entry is created at module initand persists for the module's lifetime. exports_proc_open()captures the caller's current network namespace and storesits svc_export_cache in seq->private, but takes no referenceon the namespace. If the namespace is subsequently torn down(e.g. container destruction after the opener does setns() to adifferent namespace), nfsd_net_exit() calls nfsd_export_shutdown()which frees the cache. Subsequent reads on the still-open fddereference the freed cache_detail, walking a freed hash table.Hold a reference on the struct net for the lifetime of the openfile descriptor. This prevents nfsd_net_exit() from running --and thus prevents nfsd_export_shutdown() from freeing the cache-- while any exports fd is open. cache_detail already storesits net pointer (cd->net, set by cache_create_net()), soexports_release() can retrieve it without additional per-filestorage.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_holdsco_recv_frame() reads conn->sk under sco_conn_lock() but immediatelyreleases the lock without holding a reference to the socket. A concurrentclose() can free the socket between the lock release and the subsequentsk->sk_state access, resulting in a use-after-free.Other functions in the same file (sco_sock_timeout(), sco_conn_del())correctly use sco_sock_hold() to safely hold a reference under the lock.Fix by using sco_sock_hold() to take a reference before releasing thelock, and adding sock_put() on all exit paths.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()At the end of this function, d is the traversal cursor of flist, but thecode completes found instead. This can lead to issues such as NULL pointerdereferences, double completion, or descriptor leaks.Fix this by completing d instead of found in the finallist_for_each_entry_safe() loop.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since thevalue could change in runtime, we should use num_tx_queues instead.Moreover iavf_get_ethtool_stats() uses num_active_queues whileiavf_get_sset_count() and iavf_get_stat_strings() usereal_num_tx_queues, which triggers out-of-bounds writes when we do"ethtool -L" and "ethtool -S" simultaneously [1].For example when we change channels from 1 to 8, Thread 3 could bescheduled before Thread 2, and out-of-bounds writes could be triggeredin Thread 3:Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)iavf_set_channels()...iavf_alloc_queues()-> num_active_queues = 8iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8Use immutable num_tx_queues in all related functions to avoid the issue.[1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800 CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Make sure to use pmu_ctx->pmu for groupsOliver reported that x86_pmu_del() ended up doing an out-of-bound memory accesswhen group_sched_in() fails and needs to roll back.This *should* be handled by the transaction callbacks, but he found that whenthe group leader is a software event, the transaction handlers of the wrong PMUare used. Despite the move_group case in perf_event_open() and group_sched_in()using pmu_ctx->pmu.Turns out, inherit uses event->pmu to clone the events, effectively undoing themove_group case for all inherited contexts. Fix this by also making inherit usepmu_ctx->pmu, ensuring all inherited counters end up in the same pmu context.Similarly, __perf_event_read() should use equally use pmu_ctx->pmu for thegroup case.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix use-after-free in -EBUSY error path of tls_do_encryptionThe -EBUSY handling in tls_do_encryption(), introduced by commit859054147318 ("net: tls: handle backlogging of crypto requests"), hasa use-after-free due to double cleanup of encrypt_pending and thescatterlist entry.When crypto_aead_encrypt() returns -EBUSY, the request is enqueued tothe cryptd backlog and the async callback tls_encrypt_done() will beinvoked upon completion. That callback unconditionally restores thescatterlist entry (sge->offset, sge->length) and decrementsctx->encrypt_pending. However, if tls_encrypt_async_wait() returns anerror, the synchronous error path in tls_do_encryption() performs thesame cleanup again, double-decrementing encrypt_pending anddouble-restoring the scatterlist.The double-decrement corrupts the encrypt_pending sentinel (initializedto 1), making tls_encrypt_async_wait() permanently skip the wait forpending async callbacks. A subsequent sendmsg can then free thetls_rec via bpf_exec_tx_verdict() while a cryptd callback is stillpending, resulting in a use-after-free when the callback fires on thefreed record.Fix this by skipping the synchronous cleanup when the -EBUSY asyncwait returns an error, since the callback has already handledencrypt_pending and sge restoration.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gw: fix OOB heap access in cgw_csum_crc8_rel()cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return;However, the loop and the result write then use the raw s8 fields directlyinstead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates withi = -64, reading cf->data[-64], and the write goes to cf->data[-64].This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before thestart of the canfd_frame on the heap.The companion function cgw_csum_xor_rel() uses `from`/`to`/`res`correctly throughout; fix cgw_csum_crc8_rel() to match.Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesseswb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the lastreference, the blkcg can be freed asynchronously (css_free_rwork_fn ->blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences thepointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)** Stack based on commit 66672af7a095 ("Add linux-next specific filesfor 20260410")I am seeing this crash sporadically in Meta fleet across multiple kernelversions. A full reproducer is available at:https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh(The race window is narrow. To make it easily reproducible, inject amsleep(100) between css_put() and blkcg_unpin_online() incgwb_release_workfn(). With that delay and a KASAN-enabled kernel, thereproducer triggers the splat reliably in less than a second.)Fix this by moving blkcg_unpin_online() before css_put(), so thecgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online()accesses it.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Use scratch field in MMIO fragment to hold small write valuesWhen exiting to userspace to service an emulated MMIO write, copy theto-be-written value to a scratch field in the MMIO fragment if the sizeof the data payload is 8 bytes or less, i.e. can fit in a single chunk,instead of pointing the fragment directly at the source value.This fixes a class of use-after-free bugs that occur when the emulatorinitiates a write using an on-stack, local variable as the source, thewrite splits a page boundary, *and* both pages are MMIO pages. BecauseKVM's ABI only allows for physically contiguous MMIO requests, accessesthat split MMIO pages are separated into two fragments, and are sent touserspace one at a time. When KVM attempts to complete userspace MMIO inresponse to KVM_RUN after the first fragment, KVM will detect the secondfragment and generate a second userspace exit, and reference the on-stackvariable.The issue is most visible if the second KVM_RUN is performed by a separatetask, in which case the stack of the initiating task can show up as trulyfreed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================The bug can also be reproduced with a targeted KVM-Unit-Test by hackingKVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. byoverwrite the data value with garbage.Limit the use of the scratch fields to 8-byte or smaller accesses, and tojust writes, as larger accesses and reads are not affected thanks toimplementation details in the emulator, but add a sanity check to ensurethose details don't change in the future. Specifically, KVM never useson-stack variables for accesses larger that 8 bytes, e.g. uses an operandin the emulator context, and *al---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeatA use-after-free / refcount underflow is possible when the heartbeatworker and intel_engine_park_heartbeat() race to release the sameengine->heartbeat.systole request.The heartbeat worker reads engine->heartbeat.systole and callsi915_request_put() on it when the request is complete, but clearsthe pointer in a separate, non-atomic step. Concurrently, a requestretirement on another CPU can drop the engine wakeref to zero, triggering__engine_park() -> intel_engine_park_heartbeat(). If the heartbeattimer is pending at that point, cancel_delayed_work() returns true andintel_engine_park_heartbeat() reads the stale non-NULL systole pointerand calls i915_request_put() on it again, causing a refcount underflow:```<4> [487.221889] Workqueue: i915-unordered engine_retire [i915]<4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0...<4> [487.222707] Call Trace:<4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]<4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]<4> [487.223566] __engine_park+0xb9/0x650 [i915]<4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]<4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]<4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]<4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915]<4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]<4> [487.226178] i915_request_retire+0x1c/0x40 [i915]<4> [487.226625] engine_retire+0x122/0x180 [i915]<4> [487.227037] process_one_work+0x239/0x760<4> [487.227060] worker_thread+0x200/0x3f0<4> [487.227068] ? __pfx_worker_thread+0x10/0x10<4> [487.227075] kthread+0x10d/0x150<4> [487.227083] ? __pfx_kthread+0x10/0x10<4> [487.227092] ret_from_fork+0x3d4/0x480<4> [487.227099] ? __pfx_kthread+0x10/0x10<4> [487.227107] ret_from_fork_asm+0x1a/0x30<4> [487.227141] ```Fix this by replacing the non-atomic pointer read + separate clear withxchg() in both racing paths. xchg() is a single indivisible hardwareinstruction that atomically reads the old pointer and writes NULL. Thisguarantees only one of the two concurrent callers obtains the non-NULLpointer and performs the put, the other gets NULL and skips it.(cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix slab-use-after-free in __inet_lookup_establishedThe ehash table lookups are lockless and rely onSLAB_TYPESAFE_BY_RCU to guarantee socket memory stabilityduring RCU read-side critical sections. Both tcp_prot andtcpv6_prot have their slab caches created with this flagvia proto_register().However, MPTCP's mptcp_subflow_init() copies tcpv6_prot intotcpv6_prot_override during inet_init() (fs_initcall, level 5),before inet6_init() (module_init/device_initcall, level 6) hascalled proto_register(&tcpv6_prot). At that point,tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slabremains NULL permanently.This causes MPTCP v6 subflow child sockets to be allocated viakmalloc (falling into kmalloc-4k) instead of the TCPv6 slabcache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, sowhen these sockets are freed without SOCK_RCU_FREE (which iscleared for child sockets by design), the memory can beimmediately reused. Concurrent ehash lookups underrcu_read_lock can then access freed memory, triggering aslab-use-after-free in __inet_lookup_established.Fix this by splitting the IPv6-specific initialization out ofmptcp_subflow_init() into a new mptcp_subflow_v6_init(), calledfrom mptcp_proto_v6_init() before protocol registration. Thisensures tcpv6_prot_override.slab correctly inherits theSLAB_TYPESAFE_BY_RCU slab cache.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr pointsdirectly into the mmap'd TX ring buffer shared with userspace. Thekernel validates the header via __packet_snd_vnet_parse() but thenre-reads all fields later in virtio_net_hdr_to_skb(). A concurrentuserspace thread can modify the vnet_hdr fields between validationand use, bypassing all safety checks.The non-TPACKET path (packet_snd()) already correctly copies vnet_hdrto a stack-local variable. All other vnet_hdr consumers in the kernel(tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TXpath is the only caller of virtio_net_hdr_to_skb() that reads directlyfrom user-controlled shared memory.Fix this by copying vnet_hdr from the mmap'd ring buffer to astack-local variable before validation and use, consistent with theapproach used in packet_snd() and all other callers.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: validate ND option lengths in vxlan_na_createvxlan_na_create() walks ND options according to option-providedlengths. A malformed option can make the parser advance beyond thecomputed option 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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: ignore explicit helper on new expectationsUse the existing master conntrack helper, anything else is not reallysupported and it just makes validation more complicated, so just ignorewhat helper userspace suggests for this expectation.This was uncovered when validating CTA_EXPECT_CLASS via different helperprovided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350Allowing to read kernel memory bytes off the expectation boundary.CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspacevia netlink dump.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_helper: pass helper to expect cleanupnf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()to remove expectations belonging to the helper being unregistered.However, it passes NULL instead of the helper pointer as the dataargument, so expect_iter_me() never matches any expectation and allof them survive the cleanup.After unregister returns, nfnl_cthelper_del() frees the helperobject immediately. Subsequent expectation dumps or packet-driveninit_conntrack() calls then dereference the freed exp->helper,causing a use-after-free.Pass the actual helper pointer so expectations referencing it areproperly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: lec: fix use-after-free in sock_def_readable()A race condition exists between lec_atm_close() setting priv->lecdto NULL and concurrent access to priv->lecd in send_to_lecd(),lec_handle_bridge(), and lec_atm_send(). When the socket is freedvia RCU while another thread is still using it, a use-after-freeoccurs in sock_def_readable() when accessing the socket's wait queue.The root cause is that lec_atm_close() clears priv->lecd withoutany synchronization, while callers dereference priv->lecd withoutany protection against concurrent teardown.Fix this by converting priv->lecd to an RCU-protected pointer:- Mark priv->lecd as __rcu in lec.h- Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment- Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach()- Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd- Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock.- Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns.v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue().Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with "Connection to localhost closed by remote host", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with "make W=1 net/atm/lec.o" passes cleanly.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86: shadow stacks: proper error handling for mmap lock김영민 reports that shstk_pop_sigframe() doesn't check for errors frommmap_read_lock_killable(), which is a silly oversight, and also showsthat we haven't marked those functions with "__must_check", which wouldhave immediately caught it.So let's fix both issues.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: mixer: oss: Add card disconnect checkpointsALSA OSS mixer layer calls the kcontrol ops rather individually, andpending calls might be not always caught at disconnecting the device.For avoiding the potential UAF scenarios, add sanity checks of thecard disconnection at each entry point of OSS mixer accesses. Therwsem is taken just before that check, hence the rest context shouldbe covered by that properly.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2()Add SRCU read-side protection when reading PDPTR registers in__get_sregs2().Reading PDPTRs may trigger access to guest memory:kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() ->kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot()kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(),which uses srcu_dereference_check() and requires either kvm->srcu orkvm->slots_lock to be held. Currently only vcpu->mutex is held,triggering lockdep warning:=============================WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot6.12.59+ #3 Not taintedinclude/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: check if target buffer list is still legacy on recycleThere's a gap between when the buffer was grabbed and when itpotentially gets recycled, where if the list is empty, someone could'veupgraded it to a ring provided type. This can happen if the requestis forced via io-wq. The legacy recycling is missing checking if thebuffer_list still exists, and if it's of the correct type. Add thosechecks.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix bpf_xdp_store_bytes proto for read-only argWhile making some maps in Cilium read-only from the BPF side, we noticedthat the bpf_xdp_store_bytes proto is incorrect. In particular, theverifier was throwing the following error: ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpf_xdp_store_bytes#190 write into map forbidden, value_size=6 off=0 size=4nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE.The verifier checks the helper's memory access to R3 incheck_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The thirdargument has expected type ARG_PTR_TO_UNINIT_MEM, which includes theMEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3.Given R3 points to a read-only map, the check fails.Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper readingfrom uninitialized memory.This patch simply fixes the expected argument type to match that ofbpf_skb_store_bytes.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix workqueue list corruption by removing work_listThe commit e1168f0 ("RDMA/iwcm: Simplify cm_event_handler()")changed the work submission logic to unconditionally callqueue_work() with the expectation that queue_work() wouldhave no effect if work was already pending. The problem isthat a free list of struct iwcm_work is used (for whichstruct work_struct is embedded), so each call to queue_work()is basically unique and therefore does indeed queue the work.This causes a problem in the work handler which walks the work_listuntil it's empty to process entries. This means that a singlerun of the work handler could process item N+1 and release itback to the free list while the actual workqueue entry is stillqueued. It could then get reused (INIT_WORK...) and lead tolist corruption in the workqueue logic.Fix this by just removing the work_list. The workqueue alreadydoes this for us.This fixes the following error that was observed when stresstesting with ucmatose on an Intel E830 in iWARP mode:[ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08)[ 151.466639] ------------[ cut here ]------------[ 151.466986] kernel BUG at lib/list_debug.c:67![ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary)[ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 151.469192] Workqueue: 0x0 (iw_cm_wq)[ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100[ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90[ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046[ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027[ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600[ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff[ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68[ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000[ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000[ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0[ 151.475895] PKRU: 55555554[ 151.476118] Call Trace:[ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0[ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0[ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0[ 151.477479] process_scheduled_works+0x1c8/0x410[ 151.477823] worker_thread+0x125/0x260[ 151.478108] ? __pfx_worker_thread+0x10/0x10[ 151.478430] kthread+0xfe/0x240[ 151.478671] ? __pfx_kthread+0x10/0x10[ 151.478955] ? __pfx_kthread+0x10/0x10[ 151.479240] ret_from_fork+0x208/0x270[ 151.479523] ? __pfx_kthread+0x10/0x10[ 151.479806] ret_from_fork_asm+0x1a/0x30[ 151.480103]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix race condition in QP timer handlersI encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0... libsha1 [last unloaded: ip6_udp_tunnel] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400The issue is caused by a race condition between retransmit_timer() andrxe_destroy_qp, leading to the Queue Pair's (QP) reference count droppingto zero during timer handler execution.It seems this warning is harmless because rxe_qp_do_cleanup() will flushall pending timers and requests.Example of flow causing the issue:CPU0 CPU1retransmit_timer() { spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore} spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore }Ensure the QP's reference count is maintained and its validity is checkedwithin the timer callbacks by adding calls to rxe_get(qp) and correspondingrxe_put(qp) after use.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix tcx/netkit detach permissions when prog fd isn't givenThis commit fixes a security issue where BPF_PROG_DETACH on tcx ornetkit devices could be executed by any user when no program fd wasprovided, bypassing permission checks. The fix adds a capabilitycheck for CAP_NET_ADMIN or CAP_SYS_ADMIN in this case.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: aloop: Fix peer runtime UAF during format-change stoploopback_check_format() may stop the capture side when playback startswith parameters that no longer match a running capture stream. Commit826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") movedthe peer lookup under cable->lock, but the actual snd_pcm_stop() stillruns after dropping that lock.A concurrent close can clear the capture entry from cable->streams[] anddetach or free its runtime while the playback trigger path still holds astale peer substream pointer.Keep a per-cable count of in-flight peer stops before droppingcable->lock, and make free_cable() wait for those stops beforedetaching the runtime. This preserves the existing behavior whilemaking the peer runtime lifetime explicit.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: fix out-of-bounds read in smb2_compound_op()If a server sends a truncated response but a large OutputBufferLength, andterminates the EA list early, check_wsl_eas() returns success withoutvalidating that the entire OutputBufferLength fits within iov_len.Then smb2_compound_op() does: memcpy(idata->wsl.eas, data[0], size[0]);Where size[0] is OutputBufferLength. If iov_len is smaller than size[0],memcpy can read beyond the end of the rsp_iov allocation and leak adjacentkernel heap memory.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: ah: account for ESN high bits in async callbacksAH allocates its temporary auth/ICV layout differently when ESN is enabled:the async ahash setup appends a 4-byte seqhi slot before the ICV orauth_data area, but the async completion callbacks still reconstruct thetemporary layout as if seqhi were absent.With an async AH implementation selected, that makes AH copy or comparethe wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AHwith ESN and forced async hmac(sha1), ping fails with 100% packet loss,and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36Reconstruct the callback-side layout the same way the setup path built itby skipping the ESN seqhi slot before locating the saved auth_data or ICV.Per RFC 4302, the ESN high-order 32 bits participate in the AH ICVcomputation, so the async callbacks must account for the seqhi slot.Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro showsthe corrected offset (ah4 output_done: esn=1 err=0 icv_off=24expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.obuild clean at W=1. IPv6 AH+ESN was not exercised at runtime, and thechange has not been tested against a real async hardware AH engine.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ct: Only release RCU read lock after ct_ftWhen looking up a flow table in act_ct in tcf_ct_flow_table_get(),rhashtable_lookup_fast() internally opens and closes an RCU read criticalsection before returning ct_ft.The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero()is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ftobject. This vulnerability can lead to privilege escalation.Analysis from zdi-disclosures@trendmicro.com:When initializing act_ct, tcf_ct_init() is called, which internally triggerstcf_ct_flow_table_get().static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params){ struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ...}static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params){ void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj;}At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ftfrom zones_ht . The lookup is performed within an RCU read critical sectionthrough rcu_read_lock() / rcu_read_unlock(), which prevents the object frombeing freed. However, at the point of function return, rcu_read_unlock() hasalready been called, and there is nothing preventing ct_ft from being freedbefore reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomesthe race window, during which ct_ft can be freed.Free Process:tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu()tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put().static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft){ if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); }}At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU workstatic void tcf_ct_flow_table_cleanup_work(struct work_struct *work){ struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE);}tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executesbetween [1] and [2], UAF occurs.This race condition has a very short race window, making it generallydifficult to trigger. Therefore, to trigger the vulnerability an msleep(100) wasinserted after[1]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: use list_del_rcu for netlink hooksnft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks needto use list_del_rcu(), this list can be walked by concurrent dumpers.Add a new helper and use it consistently.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "net/smc: Introduce TCP ULP support"This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.As reported by Al Viro, the TCP ULP support for SMC is fundamentallybroken. The implementation attempts to convert an active TCP socketinto an SMC socket by modifying the underlying `struct file`, dentry,and inode in-place, which violates core VFS invariants that assumethese structures are immutable for an open file, creating a risk ofuse after free errors and general system instability.Given the severity of this design flaw and the fact that cleaneralternatives (e.g., LD_PRELOAD, BPF) exist for legacy applicationtransparency, the correct course of action is to remove this featureentirely.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, XInclude substitution performed by Nokogiri::XML::Node#do_xinclude replaced each in place, freeing the include node along with its children (such as and its descendants) and any namespaces declared on them. If an application had already exposed one of those nodes or namespaces to Ruby, the corresponding Ruby object was left pointing at freed memory. Using the object could result in invalid reads or writes to memory. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.12.1).
-
Description: libexpat before 2.8.2 has an integer overflow in storeAtts.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: libexpat before 2.8.2 has an integer overflow in addBinding.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: libexpat before 2.8.2 has an integer overflow in getAttributeId.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: libexpat before 2.8.2 has an integer overflow in copyString.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: xmlwf in libexpat before 2.8.2 has an integer overflow in endDoctypeDecl via NOTATION declarations.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_mass_storage: Fix potential integer overflow in check_command_size_in_blocks()The `check_command_size_in_blocks()` function calculates the data sizein bytes by left shifting `common->data_size_from_cmnd` by the blocksize (`common->curlun->blkbits`). However, it does not validate whetherthis shift operation will cause an integer overflow.Initially, the block size is set up in `fsg_lun_open()` , and the`common->data_size_from_cmnd` is set up in `do_scsi_command()`. Duringinitialization, there is no integer overflow check for the interactionbetween two variables.So if a malicious USB host sends a SCSI READ or WRITE commandrequesting a large amount of data (`common->data_size_from_cmnd`), theleft shift operation can wrap around. This results in a truncated datasize, which can bypass boundary checks and potentially lead to memorycorruption or out-of-bounds accesses.Fix this by using the check_shl_overflow() macro to safely perform theshift and catch any overflows.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-urllib3 > 0-0 (version in image is 2.0.7-150400.7.27.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix memory leak in verify_headerThe function sets `*ns = NULL` on every call, leaking the namespacestring allocated in previous iterations when multiple profiles areunpacked. This also breaks namespace consistency checking since *nsis always NULL when the comparison is made.Remove the incorrect assignment.The caller (aa_unpack) initializes *ns to NULL once before the loop,which is sufficient.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0530-150500.20.52.1 (version in image is 9.2.0398-150500.20.49.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bounds check in check_xattrs() to prevent out-of-bounds accessThe bounds check for the next xattr entry in check_xattrs() uses(void *)next >= end, which allows next to point within sizeof(u32)bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4bytes via *(__u32 *)(entry), which can overrun the valid xattr region.For example, if next lands at end - 1, the check passes sincenext < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1,accessing 3 bytes beyond the valid region.Fix this by changing the check to (void *)next + sizeof(u32) > end,ensuring there is always enough space for the IS_LAST_ENTRY() readon the subsequent iteration.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virt: tdx-guest: Fix handling of host controlled 'quote' buffer lengthValidate host controlled value `quote_buf->out_len` that determines howmany bytes of the quote are copied out to guest userspace. In TDXenvironments with remote attestation, quotes are not considered private,and can be forwarded to an attestation server.Catch scenarios where the host specifies a response length larger thanthe guest's allocation, or otherwise races modifying the response whilethe guest consumes it.This prevents contents beyond the pages allocated for `quote_buf`(up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace,and possibly forwarded in attestation requests.Recall that some deployments want per-container configs-tsm-reportinterfaces, so the leak may cross container protection boundaries, notjust local root.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finishLock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, asallowing userspace to manipulate and/or run a vCPU while its state is beingsynchronized would at best corrupt vCPU state, and at worst crash the hostkernel.Opportunistically assert that vcpu->mutex is held when synchronizing itsVMSA (the SEV-ES path already locks vCPUs).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbip: validate number_of_packets in usbip_pack_ret_submit()When a USB/IP client receives a RET_SUBMIT response,usbip_pack_ret_submit() unconditionally overwritesurb->number_of_packets from the network PDU. This value issubsequently used as the loop bound in usbip_recv_iso() andusbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexiblearray whose size was fixed at URB allocation time based on the*original* number_of_packets from the CMD_SUBMIT.A malicious USB/IP server can set number_of_packets in the responseto a value larger than what was originally submitted, causing a heapout-of-bounds write when usbip_recv_iso() writes tourb->iso_frame_desc[i] beyond the allocated region.KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)The server side (stub_rx.c) and gadget side (vudc_rx.c) alreadyvalidate number_of_packets in the CMD_SUBMIT path since commitsc6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handlemalicious input") and b78d830f0049 ("usbip: fix vudc_rx: hardenCMD_SUBMIT path to handle malicious input"). The server side validatesagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.On the client side we have the original URB, so we can use the tighterbound: the response must not exceed the original number_of_packets.This mirrors the existing validation of actual_length againsttransfer_buffer_length in usbip_recv_xbuff(), which checks theresponse value against the original allocation size.Kelvin Mbogo's series ("usb: usbip: fix integer overflow inusbip_recv_iso()", v2) hardens the receive-side functions themselves;this patch complements that work by catching the bad value at itssource -- in usbip_pack_ret_submit() before the overwrite -- andusing the tighter per-URB allocation bound rather than the globalUSBIP_MAX_ISO_PACKETS limit.Fix this by checking rpdu->number_of_packets againsturb->number_of_packets in usbip_pack_ret_submit() before theoverwrite. On violation, clamp to zero so that usbip_recv_iso() andusbip_pad_iso() safely return early.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Issue summary: Remote peer may exhaust heap memory of the QUICserver or client by flooding it with packets containing PATH_CHALLENGEframes.Impact summary: A malicious remote peer can cause an unboundedmemory allocation which can lead to an abnormal termination of theapplication acting as a QUIC client or server and a Denial of Service.A remote peer may exhaust heap memory by flooding the localQUIC stack with PATH_CHALLENGE frames. The local QUIC stackallocates a PATH_RESPONSE frame for every PATH_CHALLENGE it receives.The allocated PATH_RESPONSE frame gets freed only when the remotepeer acknowledges reception of the PATH_RESPONSE frame which willnot be done by a malicious peer.The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected bythis issue. The QUIC stack is outside of OpenSSL FIPS moduleboundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh < 9.6p1-150600.6.42.1 (version in image is 9.6p1-150600.6.37.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: go-git is an extensible git implementation library written in pure Go. Prior to versions 5.18.0 and 6.0.0-alpha.2, go-git may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations. This issue has been patched in versions 5.18.0 and 6.0.0-alpha.2.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
Description: Issue summary: An attacker-controlled CMP (Certificate Management Protocol)server could trigger a NULL pointer dereference in a CMP client application.Impact summary: A NULL pointer dereference causes a crash of theapplication and a Denial of Service.An attacker controlling a CMP server (or acting as a man-in-the-middle) couldcraft a CMP response containing a CRMF (Certificate Request Message Format)CertRepMessage with an EncryptedValue structure where the symmAlg fieldhas an algorithm OID but no parameters field. When the OpenSSL CMP clientprocesses this response, the NULL dereference occurs, causing a crash ofthe CMP client.Applications that process untrusted CMP/CRMF 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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
Description: etcd is a distributed key-value store for the data of a distributed system. Prior to 3.4.44, 3.5.30, and 3.6.11, a vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach leases by invoking transaction operations with these features enabled. This vulnerability is fixed in 3.4.44, 3.5.30, and 3.6.11.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
Description: Issue summary: When an application drives an AES-OCB context through thepublic EVP_Cipher() one-shot interface, the application-suppliedinitialisation vector (IV) is silently discarded.Impact summary: Every message encrypted under the same key uses thesame effective nonce regardless of the IV supplied by the caller,resulting in (key, nonce) reuse and loss of confidentiality. If thesame code path is used to compute the authentication tag, the tagdepends only on the (key, IV) pair and not on the plaintext orciphertext, allowing universal forgery of arbitrary ciphertext from asingle captured message.OpenSSL provides two ways to drive a cipher: the documented streaminginterface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-levelone-shot, EVP_Cipher(), whose documentation explicitly recommendsagainst use by applications in favour of EVP_CipherUpdate() andEVP_CipherFinal_ex(). The OCB provider's streaming handler flushesthe application-supplied IV into the OCB context before processingdata; the one-shot handler did not. Every call to EVP_Cipher() on anAES-OCB context therefore ran with the all-zero key-derived offsetstate left by cipher initialisation, regardless of the caller's IV.If EVP_EncryptFinal_ex() is subsequently used to obtain theauthentication tag, the deferred IV setup runs at that point andclears the running checksum that should have been accumulated over theplaintext. The resulting tag is a function of (key, IV) only andverifies against any ciphertext produced under the same (key, IV)pair.The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not aTLS cipher suite, and libssl does not call EVP_Cipher() in any case.Applications that drive AES-OCB through the documented streaming AEADAPI (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Onlyapplications that combine the AES-OCB cipher with the EVP_Cipher()one-shot API are vulnerable.The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected bythis issue, as AES-OCB is outside the OpenSSL FIPS module boundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Flush cache for PASID table before using itWhen writing the address of a freshly allocated zero-initialized PASIDtable to a PASID directory entry, do that after the CPU cache flush forthis PASID table, not before it, to avoid the time window when thisPASID table may be already used by non-coherent IOMMU hardware whileits contents in RAM is still some random old data, not zero-initialized.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: libcurl might in some circumstances reuse the wrong connection when asked todo an authenticated HTTP(S) request after a Negotiate-authenticated one, whenboth use the same host.libcurl features a pool of recent connections so that subsequent requests canreuse an existing connection to avoid overhead.When reusing a connection a range of criteria must be met. Due to a logicalerror in the code, a request that was issued by an application couldwrongfully reuse an existing connection to the same server that wasauthenticated using different credentials.An application that first uses Negotiate authentication to a server with`user1:password1` and then does another operation to the same server askingfor any authentication method but for `user2:password2` (while the previousconnection is still alive) - the second request gets confused and wronglyreuses the same connection and sends the new request over that connectionthinking it uses a mix of user1's and user2's credentials when it is in factstill using the connection authenticated for user1...
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri's CRuby native extension could leave a Ruby wrapper pointing to freed memory when replacing the value of an XML attribute. If Ruby code had already accessed an attribute child node, Nokogiri::XML::Attr#value= could free the underlying native child node while the wrapper remained reachable through the document node cache. A later use of the freed child node or a Ruby GC mark could dereference an invalid pointer, causing an invalid read and a possible segfault. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::Document#root= validated only that the new root was a Nokogiri::XML::Node, allowing a DTD node to be set as the document root. The result is a heap use-after-free during garbage collection or finalization, leading to an invalid memory read or potentially a segfault. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.11.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsolv-tools-base < 0.7.39-150700.11.10.1 (version in image is 0.7.35-150700.11.5.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Prevent recovery work from being queued during device removalUse disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()to ensure that no new recovery work items can be queued after deviceremoval has started. Previously, recovery work could be scheduled evenafter canceling existing work, potentially leading to use-after-freebugs if recovery accessed freed resources.Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to betterreflect its new behavior.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix UAF race between device unplug and FW event processingThe function panthor_fw_unplug() will free the FW memory sections.The problem is that there could still be pending FW events which are yetnot handled at this point. process_fw_events_work() can in this case tryto access said freed memory.Simply call disable_work_sync() to both drain and prevent futureinvocation of process_fw_events_work().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: observe an RCU grace period in macvlan_common_newlink() error pathvalis reported that a race condition still happens after my prior patch.macvlan_common_newlink() might have made @dev visible beforedetecting an error, and its caller will directly call free_netdev(dev).We must respect an RCU period, either in macvlan or the core networkingstack.After adding a temporary mdelay(1000) in macvlan_forward_source_one()to open the race window, valis repro was:ip link add p1 type veth peer p2ip link set address 00:00:00:00:00:20 dev p1ip link set up dev p1ip link set up dev p2ip link add mv0 link p2 type macvlan mode source(ip link add invalid% link p2 type macvlan mode source macaddr add00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4PING 1.2.3.4 (1.2.3.4): 56 data bytesRTNETLINK answers: Invalid argumentBUG: KASAN: slab-use-after-free in macvlan_forward_source(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)Read of size 8 at addr ffff888016bb89c0 by task e/175CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONEHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:123)print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)kasan_report (mm/kasan/report.c:597)? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)? tasklet_init (kernel/softirq.c:983)macvlan_handle_frame (drivers/net/macvlan.c:501)Allocated by task 169:kasan_save_stack (mm/kasan/common.c:58)kasan_save_track (./arch/x86/include/asm/current.h:25mm/kasan/common.c:70 mm/kasan/common.c:79)__kasan_kmalloc (mm/kasan/common.c:419)__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657mm/slub.c:7140)alloc_netdev_mqs (net/core/dev.c:12012)rtnl_create_link (net/core/rtnetlink.c:3648)rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957net/core/rtnetlink.c:4072)rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)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_sendto (net/socket.c:727 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:131)Freed by task 169:kasan_save_stack (mm/kasan/common.c:58)kasan_save_track (./arch/x86/include/asm/current.h:25mm/kasan/common.c:70 mm/kasan/common.c:79)kasan_save_free_info (mm/kasan/generic.c:587)__kasan_slab_free (mm/kasan/common.c:287)kfree (mm/slub.c:6674 mm/slub.c:6882)rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957net/core/rtnetlink.c:4072)rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)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_sendto (net/socket.c:727 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:131)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix race on rawdata dereferenceThere is a race condition that leads to a use-after-free situation:because the rawdata inodes are not refcounted, an attacker can startopen()ing one of the rawdata files, and at the same time remove thelast reference to this rawdata (by removing the corresponding profile,for example), which frees its struct aa_loaddata; as a result, whenseq_rawdata_open() is reached, i_private is a dangling pointer andfreed memory is accessed.The rawdata inodes weren't refcounted to avoid a circular refcount andwere supposed to be held by the profile rawdata reference. Howeverduring profile removal there is a window where the vfs and profiledestruction race, resulting in the use after free.Fix this by moving to a double refcount scheme. Where the profilerefcount on rawdata is used to break the circular dependency. Allowingfor freeing of the rawdata once all inode references to the rawdataare put.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix race between freeing data and fs accessing itAppArmor was putting the reference to i_private data on its end afterremoving the original entry from the file system. However the inodecan aand does live beyond that point and it is possible that some ofthe fs call back functions will be invoked after the reference hasbeen put, which results in a race between freeing the data andaccessing it through the fs.While the rawdata/loaddata is the most likely candidate to fail therace, as it has the fewest references. If properly crafted it might bepossible to trigger a race for the other types stored in i_private.Fix this by moving the put of i_private referenced data to the correctplace which is during inode eviction.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: fix OOB access in DBG_BUF_PRODUCER async event handlerThe ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER handler inbnxt_async_event_process() uses a firmware-supplied 'type' fielddirectly as an index into bp->bs_trace[] without bounds validation.The 'type' field is a 16-bit value extracted from DMA-mapped completionring memory that the NIC writes directly to host RAM. A malicious orcompromised NIC can supply any value from 0 to 65535, causing anout-of-bounds access into kernel heap memory.The bnxt_bs_trace_check_wrap() call then dereferences bs_trace->magic_byteand writes to bs_trace->last_offset and bs_trace->wrapped, leading tokernel memory corruption or a crash.Fix by adding a bounds check and defining BNXT_TRACE_MAX asDBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 to cover all currentlydefined firmware trace types (0x0 through 0xc).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Do not skip unrelated mode changes in DSC validationStarting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation inatomic check"), amdgpu resets the CRTC state mode_changed flag to false whenrecomputing the DSC configuration results in no timing change for a particularstream.However, this is incorrect in scenarios where a change in MST/DSC configurationhappens in the same KMS commit as another (unrelated) mode change. For example,the integrated panel of a laptop may be configured differently (e.g., HDRenabled/disabled) depending on whether external screens are attached. In thiscase, plugging in external DP-MST screens may result in the mode_changed flagbeing dropped incorrectly for the integrated panel if its DSC configurationdid not change during precomputation in pre_validate_dsc().At this point, however, dm_update_crtc_state() has already created new streamsfor CRTCs with DSC-independent mode changes. In turn,amdgpu_dm_commit_streams() will never release the old stream, resulting in amemory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference tothe new stream either, which manifests as a use-after-free when the stream getsdisabled later on:BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu]Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977Workqueue: events drm_mode_rmfb_work_fnCall Trace: dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980Since there is no reliable way of figuring out whether a CRTC has unrelatedmode changes pending at the time of DSC validation, remember the value of themode_changed flag from before the point where a CRTC was marked as potentiallyaffected by a change in DSC configuration. Reset the mode_changed flag to thisearlier value instead in pre_validate_dsc().(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MINThe BPF interpreter's signed 32-bit division and modulo handlers usethe kernel abs() macro on s32 operands. The abs() macro documentation(include/linux/math.h) explicitly states the result is undefined whenthe input is the type minimum. When DST contains S32_MIN (0x80000000),abs((s32)DST) triggers undefined behavior and returns S32_MIN unchangedon arm64/x86. This value is then sign-extended to u64 as0xFFFFFFFF80000000, causing do_div() to compute the wrong result.The verifier's abstract interpretation (scalar32_min_max_sdiv) computesthe mathematically correct result for range tracking, creating averifier/interpreter mismatch that can be exploited for out-of-boundsmap value access.Introduce abs_s32() which handles S32_MIN correctly by casting to u32before negating, avoiding signed overflow entirely. Replace all 8abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers.s32 is the only affected case -- the s64 division/modulo handlers donot use abs().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Fix use after free of parent_port in cxl_detach_ep()cxl_detach_ep() is called during bottom-up removal when all CXL memorydevices beneath a switch port have been removed. For each port in thehierarchy it locks both the port and its parent, removes the endpoint,and if the port is now empty, marks it dead and unregisters the portby calling delete_switch_port(). There are two places during this workwhere the parent_port may be used after freeing:First, a concurrent detach may have already processed a port by thetime a second worker finds it via bus_find_device(). Without pinningparent_port, it may already be freed when we discover port->dead andattempt to unlock the parent_port. In a production kernel that's asilent memory corruption, with lock debug, it looks like this:[]DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())[]WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310[]Call Trace:[]mutex_unlock+0xd/0x20[]cxl_detach_ep+0x180/0x400 [cxl_core][]devm_action_release+0x10/0x20[]devres_release_all+0xa8/0xe0[]device_unbind_cleanup+0xd/0xa0[]really_probe+0x1a6/0x3e0Second, delete_switch_port() releases three devm actions registeredagainst parent_port. The last of those is unregister_port() and itcalls device_unregister() on the child port, which can cascade. Ifparent_port is now also empty the device core may unregister and freeit too. So by the time delete_switch_port() returns, parent_port maybe free, and the subsequent device_unlock(&parent_port->dev) operateson freed memory. The kernel log looks same as above, with a differentoffset in cxl_detach_ep().Both of these issues stem from the absence of a lifetime guaranteebetween a child port and its parent port.Establish a lifetime rule for ports: child ports hold a reference totheir parent device until release. Take the reference when the portis allocated and drop it when released. This ensures the parent isvalid for the full lifetime of the child and eliminates the use afterfree window in cxl_detach_ep().This is easily reproduced with a reload of cxl_acpi in QEMU with CXLdevices present.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsystemd0 > 0-0 (version in image is 254.27-150600.4.62.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_conn: fix potential UAF in create_big_syncAdd hci_conn_valid() check in create_big_sync() to detect staleconnections before proceeding with BIG creation. Handle theresulting -ECANCELED in create_big_complete() and re-validate theconnection under hci_dev_lock() before dereferencing, matching thepattern used by create_le_conn_complete() and create_pa_complete().Keep the hci_conn object alive across the async boundary by takinga reference via hci_conn_get() when queueing create_big_sync(), anddropping it in the completion callback. The refcount and the lockare complementary: the refcount keeps the object allocated, whilehci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() onhdev->conn_hash, as required by hci_conn_del().hci_conn_put() is called outside hci_dev_unlock() so the final put(which resolves to kfree() via bt_link_release) does not run underhdev->lock, though the release path would be safe either way.Without this, create_big_complete() would unconditionallydereference the conn pointer on error, causing a use-after-freevia hci_connect_cfm() and hci_conn_del().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Take state lock for af_unix iterWhen a BPF iterator program updates a sockmap, there is a race condition inunix_stream_bpf_update_proto() where the `peer` pointer can become stale[1]during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ----------// unix_stream_bpf_update_proto()sk_pair = unix_peer(sk)if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair)sock_hold(sk_pair) // UaFMore practically, this fix guarantees that the iterator program isconsistently provided with a unix socket that remains stable duringiterator execution.[1]:BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7eAllocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/0xf60 unix_release+0x8a/0xf0 __sock_release+0xb0/0x270 sock_close+0x18/0x20 __fput+0x36e/0xac0 fput_close_sync+0xe5/0x1a0 __x64_sys_close+0x7d/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix differential encoding verificationDifferential encoding allows loops to be created if it is abused. Toprevent this the unpack should verify that a diff-encode chainterminates.Unfortunately the differential encode verification had two bugs.1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified.2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state.Move to a double mark scheme where already verified states get adifferent mark, than the current chain being kept. This enables usto also drop the backwards verification check that was the cause ofthe second error as any already verified state is already marked.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-server-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- grub2-x86_64-xen > 0-0 (version in image is 2.12-150700.19.29.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libusb-1_0-0 > 0-0 (version in image is 1.0.24-150400.3.3.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-server-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- util-linux > 0-0 (version in image is 2.40.4-150700.4.10.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: validate DFA start states are in bounds in unpack_pdbStart states are read from untrusted data and used as indexes into theDFA state tables. The aa_dfa_next() function call in unpack_pdb() willaccess dfa->tables[YYTD_ID_BASE][start], and if the start state exceedsthe number of states in the DFA, this results in an out-of-bound read.================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...Reject policies with out-of-bounds start states during unpackingto prevent the issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix side-effect bug in match_char() macro usageThe match_char() macro evaluates its character parameter multipletimes when traversing differential encoding chains. When invokedwith *str++, the string pointer advances on each iteration of theinner do-while loop, causing the DFA to check different charactersat each iteration and therefore skip input characters.This results in out-of-bounds reads when the pointer advances pastthe input buffer boundary.[ 94.984676] ==================================================================[ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760[ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)[ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 94.986329] Call Trace:[ 94.986341] [ 94.986347] dump_stack_lvl+0x5e/0x80[ 94.986374] print_report+0xc8/0x270[ 94.986384] ? aa_dfa_match+0x5ae/0x760[ 94.986388] kasan_report+0x118/0x150[ 94.986401] ? aa_dfa_match+0x5ae/0x760[ 94.986405] aa_dfa_match+0x5ae/0x760[ 94.986408] __aa_path_perm+0x131/0x400[ 94.986418] aa_path_perm+0x219/0x2f0[ 94.986424] apparmor_file_open+0x345/0x570[ 94.986431] security_file_open+0x5c/0x140[ 94.986442] do_dentry_open+0x2f6/0x1120[ 94.986450] vfs_open+0x38/0x2b0[ 94.986453] ? may_open+0x1e2/0x2b0[ 94.986466] path_openat+0x231b/0x2b30[ 94.986469] ? __x64_sys_openat+0xf8/0x130[ 94.986477] do_file_open+0x19d/0x360[ 94.986487] do_sys_openat2+0x98/0x100[ 94.986491] __x64_sys_openat+0xf8/0x130[ 94.986499] do_syscall_64+0x8e/0x660[ 94.986515] ? count_memcg_events+0x15f/0x3c0[ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5[ 94.986540] ? handle_mm_fault+0x1639/0x1ef0[ 94.986551] ? vma_start_read+0xf0/0x320[ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5[ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5[ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0[ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5[ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0[ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5[ 94.986588] ? irqentry_exit+0x3c/0x590[ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 94.986597] RIP: 0033:0x7fda4a79c3eaFix by extracting the character value before invoking match_char,ensuring single evaluation per outer loop.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix missing bounds check on DEFAULT table in verify_dfa()The verify_dfa() function only checks DEFAULT_TABLE bounds when the stateis not differentially encoded.When the verification loop traverses the differential encoding chain,it reads k = DEFAULT_TABLE[j] and uses k as an array index withoutvalidation. A malformed DFA with DEFAULT_TABLE[j] >= state_count,therefore, causes both out-of-bounds reads and writes.[ 57.179855] ==================================================================[ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660[ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)[ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 57.181563] Call Trace:[ 57.181572] [ 57.181577] dump_stack_lvl+0x5e/0x80[ 57.181596] print_report+0xc8/0x270[ 57.181605] ? verify_dfa+0x59a/0x660[ 57.181608] kasan_report+0x118/0x150[ 57.181620] ? verify_dfa+0x59a/0x660[ 57.181623] verify_dfa+0x59a/0x660[ 57.181627] aa_dfa_unpack+0x1610/0x1740[ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470[ 57.181640] unpack_pdb+0x86d/0x46b0[ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5[ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5[ 57.181656] ? aa_unpack_nameX+0x1a8/0x300[ 57.181659] aa_unpack+0x20b0/0x4c30[ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5[ 57.181664] ? stack_depot_save_flags+0x33/0x700[ 57.181681] ? kasan_save_track+0x4f/0x80[ 57.181683] ? kasan_save_track+0x3e/0x80[ 57.181686] ? __kasan_kmalloc+0x93/0xb0[ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780[ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130[ 57.181697] ? policy_update+0x154/0x330[ 57.181704] aa_replace_profiles+0x15a/0x1dd0[ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5[ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780[ 57.181712] ? aa_loaddata_alloc+0x77/0x140[ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5[ 57.181717] ? _copy_from_user+0x2a/0x70[ 57.181730] policy_update+0x17a/0x330[ 57.181733] profile_replace+0x153/0x1a0[ 57.181735] ? rw_verify_area+0x93/0x2d0[ 57.181740] vfs_write+0x235/0xab0[ 57.181745] ksys_write+0xb0/0x170[ 57.181748] do_syscall_64+0x8e/0x660[ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 57.181765] RIP: 0033:0x7f6192792eb2Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLEentries unconditionally.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: Fix double free of ns_name in aa_replace_profiles()if ns_name is NULL after1071 error = aa_unpack(udata, &lh, &ns_name);and if ent->ns_name contains an ns_name in1089 } else if (ent->ns_name) {then ns_name is assigned the ent->ns_name1095 ns_name = ent->ns_name;however ent->ns_name is freed at1262 aa_load_ent_free(ent);and then again when freeing ns_name at1270 kfree(ns_name);Fix this by NULLing out ent->ns_name after it is transferred to ns_name")
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: Fix previous acpi_processor_errata_piix4() fixAfter commi f132e089fe89 ("ACPI: processor: Fix NULL-pointer dereferencein acpi_processor_errata_piix4()"), device pointers may be dereferencedafter dropping references to the device objects pointed to by them,which may cause a use-after-free to occur.Moreover, debug messages about enabling the errata may be printedif the errata flags corresponding to them are unset.Address all of these issues by moving message printing to the pointsin the code where the errata flags are set.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPUReject synchronizing vCPU state to its associated VMSA if the vCPU hasalready been launched, i.e. if the VMSA has already been encrypted. On ahost with SNP enabled, accessing guest-private memory generates an RMP #PFand panics the host. BUG: unable to handle page fault for address: ff1276cbfdf36000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] Oops: Oops: 0003 [#1] SMP NOPTI CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] Call Trace: snp_launch_update_vmsa+0x19d/0x290 [kvm_amd] snp_launch_finish+0xb6/0x380 [kvm_amd] sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd] kvm_arch_vm_ioctl+0x837/0xcf0 [kvm] kvm_vm_ioctl+0x3fd/0xcc0 [kvm] __x64_sys_ioctl+0xa3/0x100 x64_sys_call+0xfe0/0x2350 do_syscall_64+0x81/0x10f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7ffff673287d Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM:Provide support to launch and run an SEV-ES guest"), but has only beenactively dangerous for the host since SNP support was added. With SEV-ES,KVM would "just" clobber guest state, which is totally fine from a hostkernel perspective since userspace can clobber guest state any time beforesev_launch_update_vmsa().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: A flaw was found in GNU Binutils. This heap-based buffer overflow vulnerability, specifically an out-of-bounds read in the bfd linker, allows an attacker to gain access to sensitive information. By convincing a user to process a specially crafted XCOFF object file, an attacker can trigger this flaw, potentially leading to information disclosure or an application level denial of service.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: A flaw was found in GNU Binutils. This vulnerability, a heap-based buffer overflow, specifically an out-of-bounds read, exists in the bfd linker component. An attacker could exploit this by convincing a user to process a specially crafted malicious XCOFF object file. Successful exploitation may lead to the disclosure of sensitive information or cause the application to crash, resulting in an application level denial of service.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: Moby is an open source container framework. In Docker Engine prior to version 29.5.1, Docker Daemon versions 28.5.2 and prior, and Moby Daemon prior to version 2.0.0-beta.14, a race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem. This issue has been patched in Docker Engine version 29.5.1 and Moby Daemon version 2.0.0-beta.14.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gzip > 0-0 (version in image is 1.10-150200.10.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handlert7xx_port_enum_msg_handler() uses the modem-supplied port_count field asa loop bound over port_msg->data[] without checking that the message buffercontains sufficient data. A modem sending port_count=65535 in a 12-bytebuffer triggers a slab-out-of-bounds read of up to 262140 bytes.Add a sizeof(*port_msg) check before accessing the port message headerfields to guard against undersized messages.Add a struct_size() check after extracting port_count and before the loop.In t7xx_parse_host_rt_data(), guard the rt_feature header read with aremaining-buffer check before accessing data_len, validate feat_data_lenagainst the actual remaining buffer to prevent OOB reads and signedinteger overflow on offset.Pass msg_len from both call sites: skb->len at the DPMAIF path afterskb_pull(), and the validated feat_data_len at the handshake path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: A flaw was found in the GNU Binutils BFD library, a widely used component for handling binary files such as object files and executables. The issue occurs when processing specially crafted XCOFF object files, where a relocation type value is not properly validated before being used. This can cause the program to read memory outside of intended bounds. As a result, affected tools may crash or expose unintended memory contents, leading to denial-of-service or limited information disclosure risks.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix improper freeing of purex itemIn qla2xxx_process_purls_iocb(), an item is allocated viaqla27xx_copy_multiple_pkt(), which internally callsqla24xx_alloc_purex_item().The qla24xx_alloc_purex_item() function may return a pre-allocated itemfrom a per-adapter pool for small allocations, instead of dynamicallyallocating memory with kzalloc().An error handling path in qla2xxx_process_purls_iocb() incorrectly useskfree() to release the item. If the item was from the pre-allocatedpool, calling kfree() on it is a bug that can lead to memory corruption.Fix this by using the correct deallocation function,qla24xx_free_purex_item(), which properly handles both dynamicallyallocated and pre-allocated items.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix use-after-free in pm8001_queue_command()Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") refactorspm8001_queue_command(), however it introduces a potential cause of a doublefree scenario when it changes the function to return -ENODEV in case of phydown/device gone state.In this path, pm8001_queue_command() updates task status and callstask_done to indicate to upper layer that the task has been handled.However, this also frees the underlying SAS task. A -ENODEV is thenreturned to the caller. When libsas sas_ata_qc_issue() receives this errorvalue, it assumes the task wasn't handled/queued by LLDD and proceeds toclean up and free the task again, resulting in a double free.Since pm8001_queue_command() handles the SAS task in this case, it shouldreturn 0 to the caller indicating that the task has been handled.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.15.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/x25: Fix overflow when accumulating packetsAdd a check to ensure that `x25_sock.fraglen` does not overflow.The `fraglen` also needs to be resetted when purging `fragment_queue` in`x25_clear_queues()`.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Only put the call ref if one was acquiredrxrpc_input_packet_on_conn() can process a to-client packet after thecurrent client call on the channel has already been torn down. In thatcase chan->call is NULL, rxrpc_try_get_call() returns NULL and there isno reference to drop.The client-side implicit-end error path does not account for that andunconditionally calls rxrpc_put_call(). This turns a protocol errorpath into a kernel crash instead of rejecting the packet.Only drop the call reference if one was actually acquired. Keep theexisting protocol error handling unchanged.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Issue Summary: Cryptographic Message Services (CMS) processing fails to performsufficient input validation on the cipher and tag length fields ofAuthEnvelopedData containers, leading to various potential compromises.Impact Summary: Attackers making use of these vulnerabilities may achievekey-equivalent functionality for a given CMS recipient and/or bypass integrityvalidation for a given message.In one use case, an attacker may send a CMS message containingAuthEnvelopedData with the cipher specified as a non-AEAD cipher. OpenSSLerroneously allows this selection, and attempts to decrypt and validate themessage.An on-path attacker who captures one legitimate AES-GCM AuthEnvelopedDataaddressed to the victim can re-emit it with the recipientInfos set leftbyte-for-byte intact, so the victim's private key still unwraps the genuine CEK(the content-encryption key), but with the inner OID rewritten to AES-256-OFB(Output Feedback Mode, an unauthenticated keystream mode) and with anattacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under thereal CEK, never consults the MAC field, and CMS_decrypt() returns success.If the application under attack responds to the attacker with any indicatorshowing success or failure of the decryption effort, it is possible for theattacker to use this as an oracle to obtain key equivalent functionality for theCEK used for the chosen recipient of the message.In another use case, an attacker can reduce the tag length of the chosen AEADcipher for a given AuthEnvelopedData container to be a single byte long,allowing an attacker to brute force CMS decryption, producing an integritybypass for applications that trust CMS_decrypt() to reject modified content.The FIPS modules are not affected by this issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 > 0-0 (version in image is 3.2.3-150700.5.31.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- krb5 > 0-0 (version in image is 1.20.1-150600.11.14.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- krb5 > 0-0 (version in image is 1.20.1-150600.11.14.1).
-
Description: lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.0, using either of the two parsers in the default configuration (with resolve_entities=True) allows untrusted XML input to read local files. Setting the resolve_entities option explicitly to resolve_entities='internal' or resolve_entities=False disables the local file access. This vulnerability is fixed in 6.1.0.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-lxml > 0-0 (version in image is 4.9.1-150500.3.4.3).
-
Description: Issue Summary: An error in the callback used to verify the certificateprovided in a Root CA key update Certificate Management Protocol (CMP)message response rendered the certificate validation ineffectual, whichcould lead to escalation of credentials from the Registration Authority (RA)level to the root Certification Authority (root CA) level.Impact Summary: The Registration Autority could replace the root CAcertificate for the CMP clients with an arbitrary root CA certificate.One of the parts of the Certificate Management Protocol (CMP), specified inRFC 9810, is Root Certification Authority (root CA) key Rollover,which is sent by the server in a message with type 'id-it-rootCaKeyUpdate'.As part of these messages, 'newWithOld' certificate, the new root CAcertificate signed with the old root CA key, is provided, and verifying itssignature is crucial for transferring the trust from the old CA key to thenew one.The 'id-it-rootCaKeyUpdate' messages are expected to be processed withOSSL_CMP_get1_rootCaKeyUpdate(), that is expected to verify the 'newWithOld'certificate. A typo in the certificate chain building code led to addingan incorrect certificate ('newWithOld' instead of 'oldRoot') to thecertificate chain, rendering the certificate verification process ineffectual(only the issuer name and the algorithm OIDs were verified by other partsof the verification code).An attacker who already has credentials that satisfy the CMP messageprotection checks can generate a new key pair and use a crafted self-signedcertificate in its 'id-it-rootCaKeyUpdate' CMP messages which affected CMPclients would accept as a new trust anchor.Significant preconditions for the attack (having valid RA-level credentials)are the reason the issue was assigned Low severity.The FIPS modules are not affected by this issue, as the affected code isoutside the OpenSSL FIPS module boundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: 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 bonding ARP/NS validation is enabled, an IPv6NS/NA packet received on a slave can reach bond_validate_na(), whichcalls bond_has_this_ip6(). That path calls ipv6_chk_addr() and cancrash in __ipv6_chk_addr_and_flags(). BUG: kernel NULL pointer dereference, address: 00000000000005d8 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:__ipv6_chk_addr_and_flags+0x69/0x170 Call Trace: ipv6_chk_addr+0x1f/0x30 bond_validate_na+0x12e/0x1d0 [bonding] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] bond_rcv_validate+0x1a0/0x450 [bonding] bond_handle_frame+0x5e/0x290 [bonding] ? srso_alias_return_thunk+0x5/0xfbef5 __netif_receive_skb_core.constprop.0+0x3e8/0xe50 ? srso_alias_return_thunk+0x5/0xfbef5 ? update_cfs_rq_load_avg+0x1a/0x240 ? srso_alias_return_thunk+0x5/0xfbef5 ? __enqueue_entity+0x5e/0x240 __netif_receive_skb_one_core+0x39/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x30/0x200 ? srso_alias_return_thunk+0x5/0xfbef5 net_rx_action+0x338/0x3b0 handle_softirqs+0xc9/0x2a0 do_softirq+0x42/0x60 __local_bh_enable_ip+0x62/0x70 __dev_queue_xmit+0x2d3/0x1000 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? packet_parse_headers+0x10a/0x1a0 packet_sendmsg+0x10da/0x1700 ? kick_pool+0x5f/0x140 ? srso_alias_return_thunk+0x5/0xfbef5 ? __queue_work+0x12d/0x4f0 __sys_sendto+0x1f3/0x220 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x101/0xf80 ? exc_page_fault+0x6e/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by checking ipv6_mod_enabled() before dispatching IPv6 packets tobond_na_rcv(). If IPv6 is disabled, return early from bond_rcv_validate()and avoid the path to ipv6_chk_addr().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- pam > 0-0 (version in image is 1.3.0-150000.6.86.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc < 2.38-150600.14.49.1 (version in image is 2.38-150600.14.46.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri contains a bug when calling certain methods on allocated-but-uninitialized native wrapper classes that inherit from Nokogiri::XML::Node. This caused a NULL pointer dereference that could crash the process. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
Description: Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, Nokogiri::XML::XPathContext did not keep its source document alive for garbage collection. If an XPathContext outlived its document and the document was collected, evaluating an XPath expression could read invalid memory and potentially segfault. This is only reachable when application code constructs an XPathContext directly and lets the document become unreachable while continuing to use the context. The normal Document#xpath, #css, and related search methods are not affected, and it is not triggerable by malicious document input. This vulnerability is fixed in 1.19.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- ruby2.5-rubygem-nokogiri > 0-0 (version in image is 1.8.5-150400.14.6.1).
-
Description: curl might erroneously pass on credentials for a first proxy to a secondproxy.This can happen when the following conditions are true:1. curl is setup to use specific different proxies for different URL schemes2. the first proxy needs credentials3. the second proxy uses no credentials4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
Description: When asked to both use a `.netrc` file for credentials and to follow HTTPredirects, libcurl could leak the password used for the first host to thefollowed-to host under certain circumstances.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl1_1 < 1.1.1w-150700.11.22.1 (version in image is 1.1.1w-150700.11.19.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix admin request_queue lifetimeThe namespaces can access the controller's admin request_queue, andstale references on the namespaces may exist after tearing down thecontroller. Ensure the admin request_queue is active by moving thecontroller's 'put' to after all controller references have been releasedto ensure no one is can access the request_queue. This fixes a reporteduse-after-free bug: BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl1_1 < 1.1.1w-150700.11.22.1 (version in image is 1.1.1w-150700.11.19.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZEThe current implementation incorrectly handles memory regions (MRs) withpage sizes different from the system PAGE_SIZE. The core issue is thatrxe_set_page() is called with mr->page_size step increments, but thepage_list stores individual struct page pointers, each representingPAGE_SIZE of memory.ib_sg_to_page() has ensured that when i>=1 eithera) SG[i-1].dma_end and SG[i].dma_addr are contiguousorb) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned.This leads to incorrect iova-to-va conversion in scenarios:1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong)Yi Zhang reported a kernel panic[1] years ago related to this defect.Solution:1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous)2. Each rxe_mr_page stores both struct page* and offset within the system page3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page4. Add boundary checks and compatibility validationThis ensures correct iova-to-va conversion regardless of MR page sizeand system PAGE_SIZE relationship, while improving performance througharray-based sequential access.Tests on 4K and 64K PAGE_SIZE hosts:- rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe- blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd[1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc < 2.38-150600.14.49.1 (version in image is 2.38-150600.14.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stack-out-of-bounds write in devmapget_upper_ifindexes() iterates over all upper devices and writes theirindices into an array without checking bounds.Also the callers assume that the max number of upper devices isMAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,but that assumption is not correct and the number of upper devices couldbe larger than MAX_NEST_DEV (e.g., many macvlans), causing astack-out-of-bounds write.Add a max parameter to get_upper_ifindexes() to avoid the issue.When there are too many upper devices, return -EOVERFLOW and abort theredirect.To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device withan XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.Then send a packet to the device to trigger the XDP redirect path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-typing_extensions < 4.12.2-150400.3.17.1 (version in image is 4.9.0-150600.1.3).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Disable works on hci_unregister_devThis make use of disable_work_* on hci_unregister_dev since the hci_dev isabout to be freed new submissions are not disarable.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- perl > 0-0 (version in image is 5.26.1-150300.17.20.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "ipmi: fix msg stack when IPMI is disconnected"This reverts commit c608966f3f9c2dca596967501d00753282b395fc.This patch has a subtle bug that can cause the IPMI driver to go into aninfinite loop if the BMC misbehaves in a certain way. Apparentlycertain BMCs do misbehave this way because several reports have come inrecently about this.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: nxp: imx8-isi: Fix streaming cleanup on releaseThe current implementation unconditionally callsmxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This canlead to situations where any release call (like from a simple"v4l2-ctl -l") may release a currently streaming queue when called onsuch a device.This is reproducible on an i.MX8MP board by streaming from an ISIcapture device using gstreamer: gst-launch-1.0 -v v4l2src device=/dev/videoX ! \ video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \ fakesinkWhile this stream is running, querying the caps of the same deviceprovokes the error state: v4l2-ctl -l -d /dev/videoXThis results in the following trace:[ 155.452152] ------------[ cut here ]------------[ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6[ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT[ 157.064369] Hardware name: imx8mp_board_01 (DT)[ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi][ 157.087126] sp : ffff800080003ee0[ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000[ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50[ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000[ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000[ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000[ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38[ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000[ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000[ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200[ 157.161850] Call trace:[ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)[ 157.170319] __handle_irq_event_percpu+0x58/0x218[ 157.175029] handle_irq_event+0x54/0xb8[ 157.178867] handle_fasteoi_irq+0xac/0x248[ 157.182968] handle_irq_desc+0x48/0x68[ 157.186723] generic_handle_domain_irq+0x24/0x38[ 157.191346] gic_handle_irq+0x54/0x120[ 157.195098] call_on_irq_stack+0x24/0x30[ 157.199027] do_interrupt_handler+0x88/0x98[ 157.203212] el0_interrupt+0x44/0xc0[ 157.206792] __el0_irq_handler_common+0x18/0x28[ 157.211328] el0t_64_irq_handler+0x10/0x20[ 157.215429] el0t_64_irq+0x198/0x1a0[ 157.219009] ---[ end trace 0000000000000000 ]---Address this issue by moving the streaming preparation and cleanup tothe vb2 .prepare_streaming() and .unprepare_streaming() operations. Thisalso simplifies the driver by allowing direct usage of thevb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal ofthe manual cleanup from mxc_isi_video_release().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()Don't add BO to the vdev->bo_list in ivpu_gem_create_object().When failure happens inside drm_gem_shmem_create(), the BO is notfully created and ivpu_gem_bo_free() callback will not be calledcausing a deleted BO to be left on the list.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: An issue was discovered in Binutils before 2.46. The objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed debug information. A logic flaw in the handling of DWARF location list headers can cause objdump to enter an unbounded loop and produce endless output until manually interrupted. This issue affects versions prior to the upstream fix and allows a local attacker to cause excessive resource consumption by supplying a malicious input file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug_rnglists data. A logic error in the handling of the debug_rnglists header can cause objdump to repeatedly print the same warning message and fail to terminate, resulting in an unbounded logging loop until the process is interrupted. The issue was observed in binutils 2.44. A local attacker can exploit this vulnerability by supplying a malicious input file, leading to excessive CPU and I/O usage and preventing completion of the objdump analysis.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF loclists data. A logic flaw in the DWARF parsing code can cause readelf to repeatedly print the same table output without making forward progress, resulting in an unbounded output loop that never terminates unless externally interrupted. A local attacker can trigger this behavior by supplying a malicious input file, causing excessive CPU and I/O usage and preventing readelf from completing its analysis.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF .debug_rnglists data. A logic flaw in the DWARF parsing path causes readelf to repeatedly print the same warning message without making forward progress, resulting in a non-terminating output loop that requires manual interruption. No evidence of memory corruption or code execution was observed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Discard Beacon frames to non-broadcast addressBeacon frames are required to be sent to the broadcast address, see IEEEStd 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frameshall be set to the broadcast address"). A unicast Beacon frame might beused as a targeted attack to get one of the associated STAs to dosomething (e.g., using CSA to move it to another channel). As such, itis better have strict filtering for this on the received side anddiscard all Beacon frames that are sent to an unexpected address.This is even more important for cases where beacon protection is used.The current implementation in mac80211 is correctly discarding unicastBeacon frames if the Protected Frame bit in the Frame Control field isset to 0. However, if that bit is set to 1, the logic used for checkingfor configured BIGTK(s) does not actually work. If the driver does nothave logic for dropping unicast Beacon frames with Protected Frame bit1, these frames would be accepted in mac80211 processing as valid Beaconframes even though they are not protected. This would allow beaconprotection to be bypassed. While the logic for checking beaconprotection could be extended to cover this corner case, a more genericcheck for discard all Beacon frames based on A1=unicast address coversthis without needing additional changes.Address all these issues by dropping received Beacon frames if they aresent to a non-broadcast address.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Drop the MHI auto_queue feature for IPCR DL channelsMHI stack offers the 'auto_queue' feature, which allows the MHI stack toauto queue the buffers for the RX path (DL channel). Though this featuresimplifies the client driver design, it introduces race between the clientdrivers and the MHI stack. For instance, with auto_queue, the 'dl_callback'for the DL channel may get called before the client driver is fully probed.This means, by the time the dl_callback gets called, the client driver'sstructures might not be initialized, leading to NULL ptr dereference.Currently, the drivers have to workaround this issue by initializing theinternal structures before calling mhi_prepare_for_transfer_autoqueue().But even so, there is a chance that the client driver's internal code pathmay call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() iscalled, leading to similar NULL ptr dereference. This issue has beenreported on the Qcom X1E80100 CRD machines affecting boot.So to properly fix all these races, drop the MHI 'auto_queue' featurealtogether and let the client driver (QRTR) manage the RX buffers manually.In the QRTR driver, queue the RX buffers based on the ring length duringprobe and recycle the buffers in 'dl_callback' once they are consumed. Thisalso warrants removing the setting of 'auto_queue' flag from controllerdrivers.Currently, this 'auto_queue' feature is only enabled for IPCR DL channel.So only the QRTR client driver requires the modification.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: mtk-smi: fix device leaks on common probeMake sure to drop the reference taken when looking up the SMI deviceduring common probe on late probe failure (e.g. probe deferral) and ondriver unbind.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: annotate data-race in ndisc_router_discovery()syzbot found that ndisc_router_discovery() could read and writein6_dev->ra_mtu without holding a lock [1]This looks fine, IFLA_INET6_RA_MTU is best effort.Add READ_ONCE()/WRITE_ONCE() to document the race.Note that we might also reject illegal MTU values(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.[1]BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discoveryread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...value changed: 0x00000000 -> 0xe5400659
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Fix memory leak in octep_device_setup()In octep_device_setup(), if octep_ctrl_net_init() fails, the functionreturns directly without unmapping the mapped resources and freeing theallocated configuration memory.Fix this by jumping to the unsupported_dev label, which performs thenecessary cleanup. This aligns with the error handling logic of otherpaths in this function.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:flex_proportions: make fprop_new_period() hardirq safeBernd has reported a lockdep splat from flexible proportions code that isessentially complaining about the following race:run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - sees odd sequence so loops indefinitelyNote that a deadlock like this is only possible if the bdi has configuredmaximum fraction of writeout throughput which is very rare in general butfrequent for example for FUSE bdis. To fix this problem we have to makesure write section of the sequence counter is irqsafe.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: annotate data-races around slave->last_rxslave->last_rx and slave->target_last_arp_rx[...] can be read and writtenlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.syzbot reported:BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validatewrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410...write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline]...value changed: 0x0000000100005365 -> 0x0000000100005366
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix memory allocation in nvme_pr_read_keys()nvme_pr_read_keys() takes num_keys from userspace and uses it tocalculate the allocation size for rse via struct_size(). The upperlimit is PR_KEYS_MAX (64K).A malicious or buggy userspace can pass a large num_keys value thatresults in a 4MB allocation attempt at most, causing a warning inthe page allocator when the order exceeds MAX_PAGE_ORDER.To fix this, use kvzalloc() instead of kzalloc().This bug has the same reasoning and fix with the patch below:https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/Warning log:WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272Modules linked in:CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0dRSP: 0018:ffffc90000fcf450 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0Call Trace: alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486 alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557 ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598 __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629 __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245 blkdev_pr_read_keys block/ioctl.c:456 [inline] blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730 blkdev_ioctl+0x299/0x700 block/ioctl.c:786 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+0x1bf/0x220 fs/ioctl.c:583 x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fb893d3108dCode: 28 c3 e8 46 1e 00 00 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 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108dRDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfigurationlink_id is taken from the ML Reconfiguration element (control & 0x000f),so it can be 0..15. link_removal_timeout[] has IEEE80211_MLD_MAX_NUM_LINKS(15) elements, so index 15 is out-of-bounds. Skip subelements withlink_id >= IEEE80211_MLD_MAX_NUM_LINKS to avoid a stack out-of-boundswrite.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: rivafb: fix divide error in nv3_arb()A userspace program can trigger the RIVA NV3 arbitration code by callingthe FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driverrecomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz(derived from the PRAMDAC MCLK PLL) as a divisor without validating itfirst.In a normal setup, state->mclk_khz is provided by the real hardware and isnon-zero. However, an attacker can construct a malicious or misconfigureddevice (e.g. a crafted/emulated PCI device) that exposes a bogus PLLconfiguration, causing state->mclk_khz to become zero. Oncenv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gnscalculation causes a divide error and crashes the kernel.Fix this by checking whether state->mclk_khz is zero and bailing out beforedoing the division.The following log reveals it:rivafb: setting virtual Y resolution to 2184divide error: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline]RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a messageWhen looking at the data in a USB urb, the actual_length is the size ofthe buffer passed to the driver, not the transfer_buffer_length which isset by the driver as the max size of the buffer.When parsing the messages in ems_usb_read_bulk_callback() properly checkthe size both at the beginning of parsing the message to make sure it isbig enough for the expected structure, and at the end of the message tomake sure we don't overflow past the end of the buffer for the nextmessage.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: equilibrium: fix warning trace on loadThe callback functions 'eqbr_irq_mask()' and 'eqbr_irq_ack()' are alsocalled in the callback function 'eqbr_irq_mask_ack()'. This is done toavoid source code duplication. The problem, is that in the function'eqbr_irq_mask()' also calles the gpiolib function 'gpiochip_disable_irq()'This generates the following warning trace in the log for every gpio onload.[ 6.088111] ------------[ cut here ]------------[ 6.092440] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:3810 gpiochip_disable_irq+0x39/0x50[ 6.097847] Modules linked in:[ 6.097847] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.59+ #0[ 6.097847] Tainted: [W]=WARN[ 6.097847] RIP: 0010:gpiochip_disable_irq+0x39/0x50[ 6.097847] Code: 39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 80 66 09 fb c3 <0f> 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40[ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046[ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008[ 6.097847] RDX: ffff888001be9000 RSI: ffff888001b2dd00 RDI: ffff888001be02a0[ 6.097847] RBP: ffffc9000000b860 R08: 0000000000000000 R09: 0000000000000000[ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514[ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000[ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS:0000000000000000[ 6.097847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0[ 6.097847] Call Trace:[ 6.097847] [ 6.097847] ? eqbr_irq_mask+0x63/0x70[ 6.097847] ? no_action+0x10/0x10[ 6.097847] eqbr_irq_mask_ack+0x11/0x60In an other driver (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) theinterrupt is not disabled here.To fix this, do not call the 'eqbr_irq_mask()' and 'eqbr_irq_ack()'function. Implement instead this directly without disabling the interrupts.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loadedbond_option_mode_set() already rejects mode changes that would make aloaded XDP program incompatible via bond_xdp_check(). However,bond_option_xmit_hash_policy_set() has no such guard.For 802.3ad and balance-xor modes, bond_xdp_check() returns false whenxmit_hash_policy is vlan+srcmac, because the 802.1q payload is usuallyabsent due to hardware offload. This means a user can:1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmit_hash_policy (e.g. layer2+3).2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.This leaves bond->xdp_prog set but bond_xdp_check() now returning falsefor the same device. When the bond is later destroyed, dev_xdp_uninstall()calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hitsthe bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when anXDP program is loaded on a bond in 802.3ad or balance-xor mode.commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP")introduced bond_xdp_check() which returns false for 802.3ad/balance-xormodes when xmit_hash_policy is vlan+srcmac. The check was wired intobond_xdp_set() to reject XDP attachment with an incompatible policy, butthe symmetric path -- preventing xmit_hash_policy from being changed to anincompatible value after XDP is already loaded -- was left unguarded inbond_option_xmit_hash_policy_set().Note:commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode")later added a similar guard to bond_option_mode_set(), butbond_option_xmit_hash_policy_set() remained unprotected.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix preempt count leak in napi poll tracepointUsing get_cpu() in the tracepoint assignment causes an obvious preemptcount leak because nothing invokes put_cpu() to undo it: softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?This clearly has seen a lot of testing in the last 3+ years...Use smp_processor_id() instead.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7996: Fix possible oob access in mt7996_mac_write_txwi_80211()Check frame length before accessing the mgmt fields inmt7996_mac_write_txwi_80211 in order to avoid a possible oob access.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/mbox: validate payload size before accessing contents in cxl_payload_from_user_allowed()cxl_payload_from_user_allowed() casts and dereferences the inputpayload without first verifying its size. When a raw mailbox commandis sent with an undersized payload (ie: 1 byte for CXL_MBOX_OP_CLEAR_LOG,which expects a 16-byte UUID), uuid_equal() reads past the allocated buffer,triggering a KASAN splat:BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xab/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x650 mm/kasan/report.c:482 kasan_report+0xce/0x100 mm/kasan/report.c:595 memcmp+0x176/0x1d0 lib/string.c:683 uuid_equal include/linux/uuid.h:73 [inline] cxl_payload_from_user_allowed drivers/cxl/core/mbox.c:345 [inline] cxl_mbox_cmd_ctor drivers/cxl/core/mbox.c:368 [inline] cxl_validate_cmd_from_user drivers/cxl/core/mbox.c:522 [inline] cxl_send_cmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643 __cxl_memdev_ioctl drivers/cxl/core/memdev.c:698 [inline] cxl_memdev_ioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa8/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdaf331ba79Code: 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:00007fdaf1d77038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768 Add 'in_size' parameter to cxl_payload_from_user_allowed() and validatethe payload is large enough.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xdp: produce a warning when calculated tailroom is negativeMany ethernet drivers report xdp Rx queue frag size as being the same asDMA write size. However, the only user of this field, namelybpf_xdp_frags_increase_tail(), clearly expects a truesize.Such difference leads to unspecific memory corruption issues under certaincircumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so whenrunning xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully usesall DMA-writable space in 2 buffers. This would be fine, if onlyrxq->frag_size was properly set to 4K, but value of 3K results in anegative tailroom, because there is a non-zero page offset.We are supposed to return -EINVAL and be done with it in such case, but dueto tailroom being stored as an unsigned int, it is reported to be somewherenear UINT_MAX, resulting in a tail being grown, even if the requestedoffset is too much (it is around 2K in the abovementioned test). This laterleads to all kinds of unspecific calltraces.[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6[ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4[ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000][ 7340.339230] in xskxceiver[42b5,400000+69000][ 7340.340300] likely on CPU 6 (core 0, socket 6)[ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe[ 7340.340888] likely on CPU 3 (core 0, socket 3)[ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7[ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI[ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy)[ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014[ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80[ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89[ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202[ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010[ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff[ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0[ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0[ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500[ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000[ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0[ 7340.421237] PKRU: 55555554[ 7340.421623] Call Trace:[ 7340.421987] [ 7340.422309] ? softleaf_from_pte+0x77/0xa0[ 7340.422855] swap_pte_batch+0xa7/0x290[ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270[ 7340.424102] zap_pte_range+0x281/0x580[ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240[ 7340.425177] unmap_page_range+0x24d/0x420[ 7340.425714] unmap_vmas+0xa1/0x180[ 7340.426185] exit_mmap+0xe1/0x3b0[ 7340.426644] __mmput+0x41/0x150[ 7340.427098] exit_mm+0xb1/0x110[ 7340.427539] do_exit+0x1b2/0x460[ 7340.427992] do_group_exit+0x2d/0xc0[ 7340.428477] get_signal+0x79d/0x7e0[ 7340.428957] arch_do_signal_or_restart+0x34/0x100[ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0[ 7340.430159] do_syscall_64+0x188/---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: io: Extract user memory type in ioremap_prot()The only caller of ioremap_prot() outside of the generic ioremap()implementation is generic_access_phys(), which passes a 'pgprot_t' valuedetermined from the user mapping of the target 'pfn' being accessed bythe kernel. On arm64, the 'pgprot_t' contains all of the non-addressbits from the pte, including the permission controls, and so we end upreturning a new user mapping from ioremap_prot() which faults whenaccessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68Extract only the memory type from the user 'pgprot_t' in ioremap_prot()and assert that we're being passed a user mapping, to protect us againstany changes in future that may require additional handling. To avoidfalsely flagging users of ioremap(), provide our own ioremap() macrowhich simply wraps __ioremap_prot().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: split gc into unlink and reclaim phaseYiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service).We must split GC in an unlink and a reclaim phase.We cannot queue elements for freeing until pointers have been swapped.Expired elements are still exposed to both the packet path and userspacedumpers via the live copy of the data structure.call_rcu() does not protect us: dump operations or element lookups startingafter call_rcu has fired can still observe the free'd element, unless thecommit phase has made enough progress to swap the clone and live pointersbefore any new reader has picked up the old version.This a similar approach as done recently for the rbtree backend in commit35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert").
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Correct speculative safety in fred_extint()array_index_nospec() is no use if the result gets spilled to the stack, asit makes the believed safe-under-speculation value subject to memorypredictions.For all practical purposes, this means array_index_nospec() must be used inthe expression that accesses the array.As the code currently stands, it's the wrong side of irqentry_enter(), and'index' is put into %ebp across the function call.Remove the index variable and reposition array_index_nospec(), so it'scalculated immediately before the array access.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251x: fix deadlock in error path of mcp251x_openThe mcp251x_open() function call free_irq() in its error path with thempc_lock mutex held. But if an interrupt already occurred theinterrupt handler will be waiting for the mpc_lock and free_irq() willdeadlock waiting for the handler to finish.This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can:mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") butfor the error path.To solve this issue move the call to free_irq() after the lock isreleased. Setting `priv->force_quit = 1` beforehand ensure that the IRQhandler will exit right away once it acquired the lock.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: fix locking for bcm_op runtime updatesCommit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates")added a locking for some variables that can be modified at runtime whenupdating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().Usually the RX_SETUP only handles and filters incoming traffic with oneexception: When the RX_RTR_FRAME flag is set a predefined CAN frame issent when a specific RTR frame is received. Therefore the rx bcm_op usesbcm_can_tx() which uses the bcm_tx_lock that was only initialized inbcm_tx_setup(). Add the missing spin_lock_init() when allocating thebcm_op in bcm_rx_setup() to handle the RTR case properly.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7925: Fix possible oob access in mt7925_mac_write_txwi_80211()Check frame length before accessing the mgmt fields inmt7925_mac_write_txwi_80211 in order to avoid a possible oob access.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: kalmia: validate USB endpointsThe kalmia driver should validate that the device it is probing has theproper number and types of USB endpoints it is expecting before it bindsto it. If a malicious device were to not have the same urbs the driverwill crash later on when it blindly accesses these endpoints.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rsi: Don't default to -EOPNOTSUPP in rsi_mac80211_configThis triggers a WARN_ON in ieee80211_hw_conf_init and isn't the expectedbehavior from the driver - other drivers default to 0 too.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fcloop: Check remoteport port_state before calling done callbackIn nvme_fc_handle_ls_rqst_work, the lsrsp->done callback is only set whenremoteport->port_state is FC_OBJSTATE_ONLINE. Otherwise, thenvme_fc_xmt_ls_rsp's LLDD call to lport->ops->xmt_ls_rsp is expected tofail and the nvme-fc transport layer itself will directly callnvme_fc_xmt_ls_rsp_free instead of relying on LLDD's done callback to freethe lsrsp resources.Update the fcloop_t2h_xmt_ls_rsp routine to check remoteport->port_state.If online, then lsrsp->done callback will free the lsrsp. Else, return-ENODEV to signal the nvme-fc transport to handle freeing lsrsp.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: change XDP RxQ frag_size from DMA write length to xdp.frame_szThe only user of frag_size field in XDP RxQ info isbpf_xdp_frags_increase_tail(). It clearly expects whole buff size insteadof DMA write size. Different assumptions in ice driver configuration leadto negative tailroom.This allows to trigger kernel panic, when usingXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to6912 and the requested offset to a huge value, e.g.XSK_UMEM__MAX_FRAME_SIZE * 100.Due to other quirks of the ZC configuration in ice, panic is not observedin ZC mode, but tailroom growing still fails when it should not.Use fill queue buffer truesize instead of DMA write size in XDP RxQ info.Fix ZC mode too by using the new helper.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearingstruct bpf_plt contains a u64 target field. Currently, the BPF JITallocator requests an alignment of 4 bytes (sizeof(u32)) for the JITbuffer.Because the base address of the JIT buffer can be 4-byte aligned (e.g.,ending in 0x4 or 0xc), the relative padding logic in build_plt() failsto ensure that target lands on an 8-byte boundary.This leads to two issues:1. UBSAN reports misaligned-access warnings when dereferencing the structure.2. More critically, target is updated concurrently via WRITE_ONCE() in bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.Fix this by increasing the allocation alignment requirement to 8 bytes(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base ofthe JIT buffer to an 8-byte boundary, allowing the relative padding mathin build_plt() to correctly align the target field.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: replace recursive profile removal with iterative approachThe profile removal code uses recursion when removing nested profiles,which can lead to kernel stack exhaustion and system crashes.Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.removeReplace the recursive __aa_profile_list_release() approach with aniterative approach in __remove_profile(). The function repeatedlyfinds and removes leaf profiles until the entire subtree is removed,maintaining the same removal semantic without recursion.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix: limit the number of levels of policy namespacesCurrently the number of policy namespaces is not bounded relying onthe user namespace limit. However policy namespaces aren't strictlytied to user namespaces and it is possible to create them and nestthem arbitrarily deep which can be used to exhaust system resource.Hard cap policy namespaces to the same depth as user namespaces.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/reg_sr: Fix leak on xa_store failureFree the newly allocated entry when xa_store() fails to avoid a memoryleak on the error path.v2: use goto fail_free. (Bala)(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: Fix circular locking dependency in rds_tcp_tunesyzbot reported a circular locking dependency in rds_tcp_tune() wheresk_net_refcnt_upgrade() is called while holding the socket lock:======================================================WARNING: possible circular locking dependency detected======================================================kworker/u10:8/15040 is trying to acquire lock:ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0},at: __kmalloc_cache_noprof+0x4b/0x6f0but task is already holding lock:ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0},at: rds_tcp_tune+0xd7/0x930The issue occurs because sk_net_refcnt_upgrade() performs memoryallocation (via get_net_track() -> ref_tracker_alloc()) while thesocket lock is held, creating a circular dependency with fs_reclaim.Fix this by moving sk_net_refcnt_upgrade() outside the socket lockcritical section. This is safe because the fields modified by thesk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are notaccessed by any concurrent code path at this point.v2: - Corrected fixes tag - check patch line wrap nits - ai commentary nits
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent concurrent access to IPSec ASO contextThe query or updating IPSec offload object is through Access ASO WQE.The driver uses a single mlx5e_ipsec_aso struct for each PF, whichcontains a shared DMA-mapped context for all ASO operations.A race condition exists because the ASO spinlock is released beforethe hardware has finished processing WQE. If a second operation isinitiated immediately after, it overwrites the shared context in theDMA area.When the first operation's completion is processed later, it readsthis corrupted context, leading to unexpected behavior and incorrectresults.This commit fixes the race by introducing a private context withineach IPSec offload object. The shared ASO context is now copied tothis private context while the ASO spinlock is held. Subsequentprocessing uses this saved, per-object context, ensuring its integrityis maintained.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igc: fix page fault in XDP TX timestamps handlingIf an XDP application that requested TX timestamping is shutting downwhile the link of the interface in use is still up the following kernelsplat is reported:[ 883.803618] [ T1554] BUG: unable to handle page fault for address: ffffcfb6200fd008...[ 883.803650] [ T1554] Call Trace:[ 883.803652] [ T1554] [ 883.803654] [ T1554] igc_ptp_tx_tstamp_event+0xdf/0x160 [igc][ 883.803660] [ T1554] igc_tsync_interrupt+0x2d5/0x300 [igc]...During shutdown of the TX ring the xsk_meta pointers are left behind, sothat the IRQ handler is trying to touch them.This issue is now being fixed by cleaning up the stale xsk meta data onTX shutdown. TX timestamps on other queues remain unaffected.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rose: fix NULL pointer dereference in rose_transmit_link on reconnectsyzkaller reported a bug [1], and the reproducer is available at [2].ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN,TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejectscalls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING(-ECONNREFUSED), but lacks a check for TCP_SYN_SENT.When rose_connect() is called a second time while the first connectionattempt is still in progress (TCP_SYN_SENT), it overwritesrose->neighbour via rose_get_neigh(). If that returns NULL, the socketis left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL.When the socket is subsequently closed, rose_release() seesROSE_STATE_1 and calls rose_write_internal() ->rose_transmit_link(skb, NULL), causing a NULL pointer dereference.Per connect(2), a second connect() while a connection is already inprogress should return -EALREADY. Add this missing check forTCP_SYN_SENT to complete the state validation in rose_connect().[1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271[2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imagination: Fix deadlock in soft reset sequenceThe soft reset sequence is currently executed from the threaded IRQhandler, hence it cannot call disable_irq() which internally waitsfor IRQ handlers, i.e. itself, to complete.Use disable_irq_nosync() during a soft reset instead.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWNuart_write_room() and uart_write() behave inconsistently whenxmit_buf is NULL (which happens for PORT_UNKNOWN ports that werenever properly initialized):- uart_write_room() returns kfifo_avail() which can be > 0- uart_write() checks xmit_buf and returns 0 if NULLThis inconsistency causes an infinite loop in drivers that rely ontty_write_room() to determine if they can write: while (tty_write_room(tty) > 0) { written = tty->ops->write(...); // written is always 0, loop never exits }For example, caif_serial's handle_tx() enters an infinite loop whenused with PORT_UNKNOWN serial ports, causing system hangs.Fix by making uart_write_room() also check xmit_buf and return 0 ifit's NULL, consistent with uart_write().Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stationsieee80211_chan_bw_change() iterates all stations and accesseslink->reserved.oper via sta->sdata->link[link_id]. For stations onAP_VLAN interfaces (e.g. 4addr WDS clients), sta->sdata points tothe VLAN sdata, whose link never participates in chanctx reservations.This leaves link->reserved.oper zero-initialized with chan == NULL,causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw()when accessing chandef->chan->band during CSA.Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata()before accessing link data.[also change sta->sdata in ARRAY_SIZE even if it doesn't matter]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix cache_request leak in cache_releaseWhen a reader's file descriptor is closed while in the middle of readinga cache_request (rp->offset != 0), cache_release() decrements therequest's readers count but never checks whether it should free therequest.In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, thecache_request is removed from the queue and freed along with its bufferand cache_head reference. cache_release() lacks this cleanup.The only other path that frees requests with readers == 0 iscache_dequeue(), but it runs only when CACHE_PENDING transitions fromset to clear. If that transition already happened while readers wasstill non-zero, cache_dequeue() will have skipped the request, and nosubsequent call will clean it up.Add the same cleanup logic from cache_read() to cache_release(): afterdecrementing readers, check if it reached 0 with CACHE_PENDING clear,and if so, dequeue and free the cache_request.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: skb: fix cross-cache free of KFENCE-allocated skb headSKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2value (e.g. 704 on x86_64) to avoid collisions with generic kmallocbucket sizes. This ensures that skb_kfree_head() can reliably useskb_end_offset to distinguish skb heads allocated fromskb_small_head_cache vs. generic kmalloc caches.However, when KFENCE is enabled, kfence_ksize() returns the exactrequested allocation size instead of the slab bucket size. If a caller(e.g. bpf_test_init) allocates skb head data via kzalloc() and therequested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, thenslab_build_skb() -> ksize() returns that exact value. After subtractingskb_shared_info overhead, skb_end_offset ends up matchingSKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly freethe object to skb_small_head_cache instead of back to the originalkmalloc cache, resulting in a slab cross-cache free: kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1kFix this by always calling kfree(head) in skb_kfree_head(). This keepsthe free path generic and avoids allocator-specific misclassificationfor KFENCE objects.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free and NULL deref in smb_grant_oplock()smb_grant_oplock() has two issues in the oplock publication sequence:1) opinfo is linked into ci->m_op_list (via opinfo_add) before add_lease_global_list() is called. If add_lease_global_list() fails (kmalloc returns NULL), the error path frees the opinfo via __free_opinfo() while it is still linked in ci->m_op_list. Concurrent m_op_list readers (opinfo_get_list, or direct iteration in smb_break_all_levII_oplock) dereference the freed node.2) opinfo->o_fp is assigned after add_lease_global_list() publishes the opinfo on the global lease list. A concurrent find_same_lease_key() can walk the lease list and dereference opinfo->o_fp->f_ci while o_fp is still NULL.Fix by restructuring the publication sequence to eliminate post-publishfailure:- Set opinfo->o_fp before any list publication (fixes NULL deref).- Preallocate lease_table via alloc_lease_table() before opinfo_add() so add_lease_global_list() becomes infallible after publication.- Keep the original m_op_list publication order (opinfo_add before lease list) so concurrent opens via same_client_has_lease() and opinfo_get_list() still see the in-flight grant.- Use opinfo_put() instead of __free_opinfo() on err_out so that the RCU-deferred free path is used.This also requires splitting add_lease_global_list() to take apreallocated lease_table and changing its return type from int to void,since it can no longer fail.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid infinite loops caused by residual dataOn the mkdir/mknod path, when mapping logical blocks to physical blocks,if inserting a new extent into the extent tree fails (in this example,because the file system disabled the huge file feature when marking theinode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() toreclaim the physical block without deleting the corresponding data inthe extent tree. This causes subsequent mkdir operations to referencethe previously reclaimed physical block number again, even though thisphysical block is already being used by the xattr block. Therefore, asituation arises where both the directory and xattr are using the samebuffer head block in memory simultaneously.The above causes ext4_xattr_block_set() to enter an infinite loop about"inserted" and cannot release the inode lock, ultimately leading to the143s blocking problem mentioned in [1].If the metadata is corrupted, then trying to remove some extent spacecan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVEwas passed, remove space wrongly update quota information.Jan Kara suggests distinguishing between two cases:1) The error is ENOSPC or EDQUOT - in this case the filesystem is fullyconsistent and we must maintain its consistency including all theaccounting. However these errors can happen only early before we'veinserted the extent into the extent tree. So current code works correctlyfor this case.2) Some other error - this means metadata is corrupted. We should strive todo as few modifications as possible to limit damage. So I'd just skipfreeing of allocated blocks.[1]INFO: task syz.0.17:5995 blocked for more than 143 seconds.Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: replace BUG_ON with proper error handling in ext4_read_inline_folioReplace BUG_ON() with proper error handling when inline data sizeexceeds PAGE_SIZE. This prevents kernel panic and allows the system tocontinue running while properly reporting the filesystem corruption.The error is logged via ext4_error_inode(), the buffer head is releasedto prevent memory leak, and -EFSCORRUPTED is returned to indicatefilesystem corruption.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: convert inline data to extents when truncate exceeds inline sizeAdd a check in ext4_setattr() to convert files from inline data storageto extent-based storage when truncate() grows the file size beyond theinline capacity. This prevents the filesystem from entering aninconsistent state where the inline data flag is set but the file sizeexceeds what can be stored inline.Without this fix, the following sequence causes a kernel BUG_ON():1. Mount filesystem with inode that has inline flag set and small size2. truncate(file, 50MB) - grows size but inline flag remains set3. sendfile() attempts to write data4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity)The crash occurs because ext4_write_inline_data() expects inline storageto accommodate the write, but the actual inline capacity (~60 bytes fori_block + ~96 bytes for xattrs) is far smaller than the file size andwrite request.The fix checks if the new size from setattr exceeds the inode's actualinline capacity (EXT4_I(inode)->i_inline_size) and converts the file toextent-based storage before proceeding with the size change.This addresses the root cause by ensuring the inline data flag and filesize remain consistent during truncate operations.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]Multiple sysfs command paths dereference contexts_arr[0] without firstverifying that kdamond->contexts->nr == 1. A user can set nr_contexts to0 via sysfs while DAMON is running, causing NULL pointer dereferences.In more detail, the issue can be triggered by privileged users likebelow.First, start DAMON and make contexts directory empty(kdamond->contexts->nr == 0). # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/nr_contextsThen, each of below commands will cause the NULL pointer dereference. # echo update_schemes_stats > state # echo update_schemes_tried_regions > state # echo update_schemes_tried_bytes > state # echo update_schemes_effective_quotas > state # echo update_tuned_intervals > stateGuard all commands (except OFF) at the entry point ofdamon_sysfs_handle_cmd().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: do not expire session on binding failureWhen a multichannel session binding request fails (e.g. wrong password),the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED.However, during binding, sess points to the target session looked up viaksmbd_session_lookup_slowpath() -- which belongs to another connection'suser. This allows a remote attacker to invalidate any active session bysimply sending a binding request with a wrong password (DoS).Fix this by skipping session expiration when the failed request wasa binding attempt, since the session does not belong to the currentconnection. The reference taken by ksmbd_session_lookup_slowpath() isstill correctly released via ksmbd_user_session_put().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: always keep track of remap prev/nextDuring 3D workload, user is reporting hitting:[ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925[ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)[ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe][ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282[ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000[ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000[ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380[ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380[ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000[ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033[ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0[ 413.362088] PKRU: 55555554[ 413.362089] Call Trace:[ 413.362092] [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe]Which seems to hint that the vma we are re-inserting for the ops unwindis either invalid or overlapping with something already inserted in thevm. It shouldn't be invalid since this is a re-insertion, so must haveworked before. Leaving the likely culprit as something already placedwhere we want to insert the vma.Following from that, for the case where we do something like a rebind inthe middle of a vma, and one or both mapped ends are already compatible,we skip doing the rebind of those vma and set next/prev to NULL. As wellas then adjust the original unmap va range, to avoid unmapping the ends.However, if we trigger the unwind path, we end up with three va, withthe two ends never being removed and the original va range in the middlestill being the shrunken size.If this occurs, one failure mode is when another unwind op needs tointeract with that range, which can happen with a vector of binds. Forexample, if we need to re-insert something in place of the original va.In this case the va is still the shrunken version, so when removing itand then doing a re-insert it can overlap with the ends, which werenever removed, triggering a warning like above, plus leaving the vm in abad state.With that, we need two things here: 1) Stop nuking the prev/next tracking for the skip cases. Instead relying on checking for skip prev/next, where needed. That way on the unwind path, we now correctly remove both ends. 2) Undo the unmap va shrinkage, on the unwind path. With the two ends now removed the unmap va should expand back to the original size again, before re-insertion.v2: - Update the explanation in the commit message, based on an actual IGT of triggering this issue, rather than conjecture. - Also undo the unmap shrinkage, for the skip case. With the two ends now removed, the original unmap va range should expand back to the original range.v3: - Track the old start/range separately. vma_size/start() uses the va info directly.(cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix missing runtime PM reference in ccs_mode_storeccs_mode_store() calls xe_gt_reset() which internally invokesxe_pm_runtime_get_noresume(). That function requires the callerto already hold an outer runtime PM reference and warns if noneis held: [46.891177] xe 0000:03:00.0: [drm] Missing outer runtime PM protection [46.891178] WARNING: drivers/gpu/drm/xe/xe_pm.c:885 at xe_pm_runtime_get_noresume+0x8b/0xc0Fix this by protecting xe_gt_reset() with the scope-basedguard(xe_pm_runtime)(xe), which is the preferred form whenthe reference lifetime matches a single scope.v2:- Use scope-based guard(xe_pm_runtime)(xe) (Shuicheng)- Update commit message accordingly(cherry picked from commit 7937ea733f79b3f25e802a0c8360bf7423856f36)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: dsi: Store driver data before invoking mipi_dsi_host_registerThe call to mipi_dsi_host_register triggers a callback to mtk_dsi_bind,which uses dev_get_drvdata to retrieve the mtk_dsi struct, so thisstructure needs to be stored inside the driver data before invoking it.As drvdata is currently uninitialized it leads to a crash whenregistering the DSI DRM encoder right after acquiringthe mode_config.idr_mutex, blocking all subsequent DRM operations.Fixes the following crash during mediatek-drm probe (tested on XiaomiSmart Clock x04g):Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[...]Modules linked in: mediatek_drm(+) drm_display_helper cec drm_client_lib drm_dma_helper drm_kms_helper panel_simple[...]Call trace: drm_mode_object_add+0x58/0x98 (P) __drm_encoder_init+0x48/0x140 drm_encoder_init+0x6c/0xa0 drm_simple_encoder_init+0x20/0x34 [drm_kms_helper] mtk_dsi_bind+0x34/0x13c [mediatek_drm] component_bind_all+0x120/0x280 mtk_drm_bind+0x284/0x67c [mediatek_drm] try_to_bring_up_aggregate_device+0x23c/0x320 __component_add+0xa4/0x198 component_add+0x14/0x20 mtk_dsi_host_attach+0x78/0x100 [mediatek_drm] mipi_dsi_attach+0x2c/0x50 panel_simple_dsi_probe+0x4c/0x9c [panel_simple] mipi_dsi_drv_probe+0x1c/0x28 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __device_attach_driver+0xbc/0x17c bus_for_each_drv+0x88/0xf0 __device_attach+0x9c/0x1cc device_initial_probe+0x54/0x60 bus_probe_device+0x34/0xa0 device_add+0x5b0/0x800 mipi_dsi_device_register_full+0xdc/0x16c mipi_dsi_host_register+0xc4/0x17c mtk_dsi_probe+0x10c/0x260 [mediatek_drm] platform_probe+0x5c/0xa4 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x24/0x30 bus_add_driver+0x11c/0x240 driver_register+0x68/0x130 __platform_register_drivers+0x64/0x160 mtk_drm_init+0x24/0x1000 [mediatek_drm] do_one_initcall+0x60/0x1d0 do_init_module+0x54/0x240 load_module+0x1838/0x1dc0 init_module_from_file+0xd8/0xf0 __arm64_sys_finit_module+0x1b4/0x428 invoke_syscall.constprop.0+0x48/0xc8 do_el0_svc+0x3c/0xb8 el0_svc+0x34/0xe8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19cCode: 52800022 941004ab 2a0003f3 37f80040 (29005a80)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardownepf_ntb_epc_destroy() duplicates the teardown that the caller issupposed to perform later. This leads to an oops when .allow_link failsor when .drop_link is performed. The following is an example oops of theformer case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...]Remove the helper, and drop pci_epc_put(). EPC device refcounting istied to the configfs EPC group lifetime, and pci_epc_put() in the.drop_link path is sufficient.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()page_pool_create() can return an ERR_PTR on failure. The return valueis used unconditionally in the loop that follows, passing the errorpointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),which dereferences it, causing a kernel oops.Add an IS_ERR check after page_pool_create() to return early on failure.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handlingSwitch from using the completion's raw spinlock to a local lock in theidpf_vc_xn struct. The conversion is safe because complete/_all() arecalled outside the lock and there is no reason to share the completionlock in the current logic. This avoids invalid wait context reported bythe kernel due to the async handler taking BH spinlock:[ 805.726977] =============================[ 805.726991] [ BUG: Invalid wait context ][ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE[ 805.727026] -----------------------------[ 805.727038] kworker/u261:0/572 is trying to lock:[ 805.727051] ff190da6a8dbb6a0 (&vport_config->mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727099] other info that might help us debug this:[ 805.727111] context-{5:5}[ 805.727119] 3 locks held by kworker/u261:0/572:[ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730[ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter->mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730[ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf][ 805.727218] stack backtrace:...[ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf][ 805.727247] Call Trace:[ 805.727249] [ 805.727251] dump_stack_lvl+0x77/0xb0[ 805.727259] __lock_acquire+0xb3b/0x2290[ 805.727268] ? __irq_work_queue_local+0x59/0x130[ 805.727275] lock_acquire+0xc6/0x2f0[ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727284] ? _printk+0x5b/0x80[ 805.727290] _raw_spin_lock_bh+0x38/0x50[ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf][ 805.727317] process_one_work+0x226/0x730[ 805.727322] worker_thread+0x19e/0x340[ 805.727325] ? __pfx_worker_thread+0x10/0x10[ 805.727328] kthread+0xf4/0x130[ 805.727333] ? __pfx_kthread+0x10/0x10[ 805.727336] ret_from_fork+0x32c/0x410[ 805.727345] ? __pfx_kthread+0x10/0x10[ 805.727347] ret_from_fork_asm+0x1a/0x30[ 805.727354]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabledKeep the NOC_HDCP clock always enabled to fix the potential hangcaused by the NoC ADB400 port power down handshake.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs()sqe->len is __u32 but gets stored into sr->len which is int. Whenuserspace passes sqe->len values exceeding INT_MAX (e.g. 0xFFFFFFFF),sr->len overflows to a negative value. This negative value propagatesthrough the bundle recv/send path: 1. io_recv(): sel.val = sr->len (ssize_t gets -1) 2. io_recv_buf_select(): arg.max_len = sel->val (size_t gets 0xFFFFFFFFFFFFFFFF) 3. io_ring_buffers_peek(): buf->len is not clamped because max_len is astronomically large 4. iov[].iov_len = 0xFFFFFFFF flows into io_bundle_nbufs() 5. io_bundle_nbufs(): min_t(int, 0xFFFFFFFF, ret) yields -1, causing ret to increase instead of decrease, creating an infinite loop that reads past the allocated iov[] arrayThis results in a slab-out-of-bounds read in io_bundle_nbufs() fromthe kmalloc-64 slab, as nbufs increments past the allocated iovecentries. BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs+0x128/0x160 Read of size 8 at addr ffff888100ae05c8 by task exp/145 Call Trace: io_bundle_nbufs+0x128/0x160 io_recv_finish+0x117/0xe20 io_recv+0x2db/0x1160Fix this by rejecting negative sr->len values early in bothio_sendmsg_prep() and io_recvmsg_prep(). Since sqe->len is __u32,any value > INT_MAX indicates overflow and is not a valid length.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/privcmd: fix double free via VMA splittingprivcmd_vm_ops defines .close (privcmd_close), but neither .may_splitnor .open. When userspace does a partial munmap() on a privcmd mapping,the kernel splits the VMA via __split_vma(). Since may_split is NULL,the split is allowed. vm_area_dup() copies vm_private_data (a pagesarray allocated in alloc_empty_pages()) into the new VMA without anyfixup, because there is no .open callback.Both VMAs now point to the same pages array. When the unmapped portionis closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages)The surviving VMA still holds the dangling pointer. When it is laterdestroyed, the same sequence runs again, which leads to a double free.Fix this issue by adding a .may_split callback denying the VMA split.This is XSA-487 / CVE-2026-31787
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libavahi-client3 < 0.8-150600.15.18.1 (version in image is 0.8-150600.15.15.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-pyOpenSSL < 21.0.0-150400.13.1 (version in image is 21.0.0-150400.10.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject sleepable kprobe_multi programs at attach timekprobe.multi programs run in atomic/RCU context and cannot sleep.However, bpf_kprobe_multi_link_attach() did not validate whether theprogram being attached had the sleepable flag set, allowing sleepablehelpers such as bpf_copy_from_user() to be invoked from a non-sleepablecontext.This causes a "sleeping function called from invalid context" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0Fix this by rejecting sleepable programs early inbpf_kprobe_multi_link_attach(), before any further processing.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: lag: Check for LAG device before creating debugfs__mlx5_lag_dev_add_mdev() may return 0 (success) even when an erroroccurs that is handled gracefully. Consequently, the initializationflow proceeds to call mlx5_ldev_add_debugfs() even when there is novalid LAG context.mlx5_ldev_add_debugfs() blindly created the debugfs directory andattributes. This exposed interfaces (like the members file) that rely ona valid ldev pointer, leading to potential NULL pointer dereferences ifaccessed when ldev is NULL.Add a check to verify that mlx5_lag_dev(dev) returns a valid pointerbefore attempting to create the debugfs entries.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready().syzbot reported use-after-free of AF_UNIX socket's sk->sk_socketin sk_psock_verdict_data_ready(). [0]In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() iscalled after dropping its unix_state_lock().Although the sender socket holds the peer's refcount, it does notprevent the peer's sock_orphan(), and the peer's sk_socket mightbe freed after one RCU grace period.Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops underRCU in sk_psock_verdict_data_ready().[0]:BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482 sock_sendmsg_nosec net/socket.c:721 [inline] __sock_sendmsg net/socket.c:736 [inline] ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674 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:0x7facf899c819Code: 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:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 Allocated by task 11013: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4538 [inline] slab_alloc_node mm/slub.c:4866 [inline] kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885 sock_alloc_inode+0x28/0xc0 net/socket.c:316 alloc_inode+0x6a/0x1b0 fs/inode.c:347 new_inode_pseudo include/linux/fs.h:3003 [inline] sock_alloc net/socket.c:631 [inline] __sock_create+0x12d/0x9d0 net/socket.c:1562 sock_create net/socket.c:1656 [inline] __sys_socketpair+0x1c4/0x560 net/socket.c:1803 __do_sys_socketpair net/socket.c:1856 [inline] __se_sys_socketpair net/socket.c:1853 [inline] __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853 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/0x7fFreed by task 15: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline] slab_free mm/slub.c:6165 [inline] kmem_cache_free+0x187/0x630 mm/slub.c:6295 rcu_do_batch kernel/rcu/tree.c:---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if existshci_cmd_sync_queue_once() needs to indicate whether a queue item wasadded, so caller can know if callbacks are called, so it can avoidleaking resources.Change the function to return -EEXIST if queue item already exists.Modify all callsites to handle that.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: set backing store type from query typebnxt_hwrm_func_backing_store_qcaps_v2() stores resp->type from thefirmware response in ctxm->type and later uses that value to indexfixed backing-store metadata arrays such as ctx_arr[] andbnxt_bstore_to_trace[].ctxm->type is fixed by the current backing-store query type and matchesthe array index of ctx->ctx_arr. Set ctxm->type from the current loopvariable instead of depending on resp->type.Also update the loop to advance type from next_valid_type in the forstatement, which keeps the control flow simpler for non-valid andunchanged entries.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: correctly handle tunneled traffic on IPV6_CSUM GSO fallbackNETIF_F_IPV6_CSUM only advertises support for checksum offload ofpackets without IPv6 extension headers. Packets with extensionheaders must fall back onto software checksumming. Since TSOdepends on checksum offload, those must revert to GSO.The below commit introduces that fallback. It always checksnetwork header length. For tunneled packets, the inner header lengthmust be checked instead. Extend the check accordingly.A special case is tunneled packets without inner IP protocol. Such asRFC 6951 SCTP in UDP. Those are not standard IPv6 followed bytransport header either, so also must revert to the software GSO path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix list corruption and UAF in command complete handlersCommit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introducedmgmt_pending_valid(), which not only validates the pending command butalso unlinks it from the pending list if it is valid. This change insemantics requires updates to several completion handlers to avoid listcorruption and memory safety issues.This patch addresses two left-over issues from the aforementioned rework:1. In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove()is replaced with mgmt_pending_free() in the success path. Sincemgmt_pending_valid() already unlinks the command at the beginning ofthe function, calling mgmt_pending_remove() leads to a double list_del()and subsequent list corruption/kernel panic.2. In set_mesh_complete(), the use of mgmt_pending_foreach() in the errorpath is removed. Since the current command is already unlinked bymgmt_pending_valid(), this foreach loop would incorrectly target otherpending mesh commands, potentially freeing them while they are still beingprocessed concurrently (leading to UAFs). The redundant mgmt_cmd_status()is also simplified to use cmd->opcode directly.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+Fix the field masks to match the hardware layout documented indownstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*).Notably this fixes a WARN I was seeing when I tried to send "stop"to the MPSS remoteproc while IPA was up.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ioam6: fix OOB and missing lockWhen trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc);This code can lead to an out-of-bounds access of the dev->_tx[] arraywhen is_input is true. In such a case, the packet is on the RX path andskb->queue_mapping contains the RX queue index of the ingress device. Ifthe ingress device has more RX queues than the egress device (dev) hasTX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues.Add a check to avoid this situation since skb_get_tx_queue() does notclamp the index. This issue has also revealed that per queue visibilitycannot be accurate and will be replaced later as a new feature.While at it, add missing lock around qdisc_qstats_qlen_backlog(). Thefunction __ioam6_fill_trace_data() is called from both softirq andprocess contexts, hence the use of spin_lock_bh() here.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix NULL deref in ip_vs_add_service error pathWhen ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the localvariable sched is set to NULL. If ip_vs_start_estimator() subsequentlyfails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULLcheck (because svc->scheduler was set by the successful bind) but thendereferences the NULL sched parameter at sched->done_service, causing akernel panic at offset 0x30 from NULL. Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) Call Trace: ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) nf_setsockopt (net/netfilter/nf_sockopt.c:102) [..]Fix by simply not clearing the local sched variable after a successfulbind. ip_vs_unbind_scheduler() already detects whether a scheduler isinstalled via svc->scheduler, and keeping sched non-NULL ensures theerror path passes the correct pointer to both ip_vs_unbind_scheduler()and ip_vs_scheduler_put().While the bug is older, the problem popups in more recent kernels (6.2),when the new error path is taken after the ip_vs_start_estimator() call.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: validate MTU against usable frame size on bindAF_XDP bind currently accepts zero-copy pool configurations withoutverifying that the device MTU fits into the usable frame space providedby the UMEM chunk.This becomes a problem since we started to respect tailroom which issubtracted from chunk_size (among with headroom). 2k chunk size mightnot provide enough space for standard 1500 MTU, so let us catch suchsettings at bind time. Furthermore, validate whether underlying HW willbe able to satisfy configured MTU wrt XSK's frame size multiplied bysupported Rx buffer chain length (that is exposed vianet_device::xdp_zc_max_segs).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: add missing negotiate_features op to Hyper-V ops tableCommit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility bynegotiating supported features") added the .negotiate_features callbackto ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgotto add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULLon Hyper-V VMs.During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(),which unconditionally dereferences hw->mac.ops.negotiate_features().On Hyper-V this results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events work_for_cpu_fn RIP: 0010:0x0 [...] Call Trace: ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...]Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP andwire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPPgracefully.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()We need to check __in6_dev_get() for possible NULL value, assuggested by Yiming Qian.Also add skb_dst_dev_rcu() instead of skb_dst_dev(),and two missing READ_ONCE().Note that @dev can't be NULL.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: verify the previous kernel's IMA buffer lies in addressable RAMPatch series "Address page fault in ima_restore_measurement_list()", v3.When the second-stage kernel is booted via kexec with a limiting commandline such as "mem=" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) not-present pageThis happens on x86_64 only, as this is already fixed in aarch64 incommit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-bufferagainst memory bounds")This patch (of 3):When the second-stage kernel is booted with a limiting command line (e.g. "mem="), the IMA measurement buffer handed over from the previouskernel may fall outside the addressable RAM of the new kernel. Accessingsuch a buffer can fault during early restore.Introduce a small generic helper, ima_validate_range(), which verifiesthat a physical [start, end] range for the previous-kernel IMA buffer lieswithin addressable memory: - On x86, use pfn_range_is_mapped(). - On OF based architectures, use page_is_ram().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable modeCommit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidationrequest when device is disconnected") relies onpci_dev_is_disconnected() to skip ATS invalidation forsafely-removed devices, but it does not cover link-down causedby faults, which can still hard-lock the system.For example, if a VM fails to connect to the PCIe device,"virsh destroy" is executed to release resources and isolatethe fault, but a hard-lockup occurs while releasing the group fd.Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry 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 __fputAlthough pci_device_is_present() is slower thanpci_dev_is_disconnected(), it still takes only ~70 ?s on aConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speedand width increase.Besides, devtlb_invalidation_with_pasid() is called only in thepaths below, which are far less frequent than memory map/unmap.1. mm-struct release2. {attach,release}_dev3. set/remove PASID4. dirty-tracking setupThe gain in system stability far outweighs the negligible costof using pci_device_is_present() instead of pci_dev_is_disconnected()to decide when to skip ATS invalidation, especially under GDRhigh-load conditions.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix NULL pointer dereferenceIf there's a mismatch between the DAI links in the machine driver andthe topology, it is possible that the playback/capture widget is notset, especially in the case of loopback capture for echo referencewhere we use the dummy DAI link. Return the error when the widget is notset to avoid a null pointer dereference like below when the topology isbroken.RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/arm-cmn: Reject unsupported hardware configurationsSo far we've been fairly lax about accepting both unknown CMN models(at least with a warning), and unknown revisions of those which wedo know, as although things do frequently change between releases,typically enough remains the same to be somewhat useful for at leastsome basic bringup checks. However, we also make assumptions of themaximum supported sizes and numbers of things in various places, andthere's no guarantee that something new might not be bigger and leadto nasty array overflows. Make sure we only try to run on things thatactually match our assumptions and so will not risk memory corruption.We have at least always failed on completely unknown node types, soupdate that error message for clarity and consistency too.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: xscale: Check for PTP support properlyIn ixp4xx_get_ts_info() ixp46x_ptp_find() is calledunconditionally despite this feature only existing onixp46x, leading to the following splat from tcpdump:root@OpenWrt:~# tcpdump -vv -X -i eth0(...)Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read(...)Call trace: ptp_clock_index from ixp46x_ptp_find+0x1c/0x38 ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64 ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108 __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648 __dev_ethtool from dev_ethtool+0x160/0x234 dev_ethtool from dev_ioctl+0x2cc/0x460 dev_ioctl from sock_ioctl+0x1ec/0x524 sock_ioctl from sys_ioctl+0x51c/0xa94 sys_ioctl from ret_fast_syscall+0x0/0x44 (...)Segmentation faultCheck for ixp46x in ixp46x_ptp_find() before trying to set upPTP to avoid this.To avoid altering the returned error code from ixp4xx_hwtstamp_set()which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPPfrom ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matterthe error code. The helper function ixp46x_ptp_find() helperreturns -ENODEV.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix signededness bug in smb_direct_prepare_negotiation()smb_direct_prepare_negotiation() casts an unsigned __u32 valuefrom sp->max_recv_size and req->preferred_send_size to a signedint before computing min_t(int, ...). A maliciously providedpreferred_send_size of 0x80000000 will return as smaller thanmax_recv_size, and then be used to set the maximum allowedalowed receive size for the next message.By sending a second message with a large value (>1420 bytes)the attacker can then achieve a heap buffer overflow.This fix replaces min_t(int, ...) with min_t(u32)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()On the receive path, __ioam6_fill_trace_data() uses trace->nodelento decide how much data to write for each node. It trusts this fieldas-is from the incoming packet, with no consistency check againsttrace->type (the 24-bit field that tells which data items arepresent). A crafted packet can set nodelen=0 while setting type bits0-21, causing the function to write ~100 bytes past the allocatedregion (into skb_shared_info), which corrupts adjacent heap memoryand leads to a kernel panic.Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c toderive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.Per RFC 9197, bits 12-21 are each short (4-octet) fields, so theyare included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to0xff1ffc00).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35[Why]A backport of the change made for DCN401 that addresses an issue wherewe turn off the PHY PLL when disabling TMDS output, which causes theOTG to remain stuck.The OTG being stuck can lead to a hang in the DCHVM's ability to ACKinvalidations when it thinks the HUBP is still on but it's not receivingglobal sync.The transition to PLL_ON needs to be atomic as there's no guaranteethat the thread isn't pre-empted or is able to complete before theIOMMU watchdog times out.[How]Backport the implementation from dcn401 back to dcn35.There's a functional difference in when the eDP output is disabled indcn401 code so we don't want to utilize it directly.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address queryFix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() byreplacing mlx5_query_mac_address() with ether_addr_copy() to get thelocal MAC address directly from netdev->dev_addr.The issue occurs because mlx5_query_mac_address() queries the hardwarewhich involves mlx5_cmd_exec() that can sleep, but it is called fromthe mlx5e_ipsec_handle_event workqueue which runs in atomic context.The MAC address is already available in netdev->dev_addr, so no needto query hardware. This avoids the sleeping call and resolves the bug.Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 __schedule+0x7ab/0xa20 schedule+0x1c/0xb0 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash()Commit 38a6f0865796 ("net: sched: support hash selecting tx queue")added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size iscomputed as:mapping_mod = queue_mapping_max - queue_mapping + 1;The range size can be 65536 when the requested range covers all possibleu16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX).That value cannot be represented in a u16 and previously wrapped to 0,so tcf_skbedit_hash() could trigger a divide-by-zero:queue_mapping += skb_get_hash(skb) % params->mapping_mod;Compute mapping_mod in a wider type and reject ranges larger than U16_MAXto prevent params->mapping_mod from becoming 0 and avoid the crash.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kexec: add a sanity check on previous kernel's ima kexec bufferWhen the second-stage kernel is booted via kexec with a limiting commandline such as "mem=", the physical range that contains the carriedover IMA measurement list may fall outside the truncated RAM leading to akernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) - not-present pageOther architectures already validate the range with page_is_ram(), as donein commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-bufferagainst memory bounds") do a similar check on x86.Without carrying the measurement list across kexec, the attestationwould fail.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: move vdpa group bound check to vhost_vdpaRemove duplication by consolidating these here. This reduces theposibility of a parent driver missing them.While we're at it, fix a bug in vdpa_sim where a valid ASID can beassigned to a group equal to ngroups, causing an out of bound write.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: in-kernel: always set ID as avail when rm endpSyzkaller managed to find a combination of actions that was generatingthis warning: WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline] RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tun_chr_ioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline] mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282 genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:733 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608 ___sys_sendmsg+0x2de/0x320 net/socket.c:2662 __sys_sendmsg net/socket.c:2694 [inline] __do_sys_sendmsg net/socket.c:2699 [inline] __se_sys_sendmsg net/socket.c:2697 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: 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 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix RSS context delete logicWe need to free the corresponding RSS context VNICin FW everytime an RSS context is deleted in driver.Commit 667ac333dbb7 added a check to delete the VNICin FW only when netif_running() is true to help deleteRSS contexts with interface down.Having that condition will make the driver leak VNICsin FW whenever close() happens with active RSS contexts.On the subsequent open(), as part of RSS context restoration,we will end up trying to create extra VNICs for which wedid not make any reservation. FW can fail this request,thereby making us lose active RSS contexts.Suppose an RSS context is deleted already and we try toprocess a delete request again, then the HWRM functionswill check for validity of the request and they simplyreturn if the resource is already freed. So, even fordelete-when-down cases, netif_running() check is notnecessary.Remove the netif_running() condition check when deletingan RSS context.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: chips-media: wave5: Fix Null reference while testing flusterWhen multi instances are created/destroyed, many interrupts happensand structures for decoder are removed."struct vpu_instance" this structure is shared for all flow in the decoder,so if the structure is not protected by lock, Null dereferencecould happens sometimes.IRQ Handler was spilt to two phases and Lock was added as well.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kexec: derive purgatory entry from symbolkexec_load_purgatory() derives image->start by locating e_entry inside anSHF_EXECINSTR section. If the purgatory object contains multipleexecutable sections with overlapping sh_addr, the entrypoint check canmatch more than once and trigger a WARN.Derive the entry section from the purgatory_start symbol when present andcompute image->start from its final placement. Keep the existing e_entryfallback for purgatories that do not expose the symbol.WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e[me@linux.beauty: move helper to avoid forward declaration, per Baoquan]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panelsSince commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")we may get the following kernel panic, for some panels, when rebooting: systemd-shutdown[1]: Rebooting. Call trace: ... do_serror+0x28/0x68 el1h_64_error_handler+0x34/0x50 el1h_64_error+0x6c/0x70 rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P) mipi_dsi_device_transfer+0x44/0x58 mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4 ili9881c_unprepare+0x38/0x88 drm_panel_unprepare+0xbc/0x108This happens for panels that need to send MIPI-DSI commands in theirunprepare() callback. Since the MIPI-DSI interface is stopped at thatpoint, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic.Fix by moving rzg2l_mipi_dsi_stop() to new callback functionrzg2l_mipi_dsi_atomic_post_disable().With this change we now have the correct power-down/stop sequence: systemd-shutdown[1]: Rebooting. rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry reboot: Restarting system
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip vcn poison irq release on VFVF doesn't enable VCN poison irq in VCNv2.5. Skip releasing it and avoidcall trace during deinitialization.[ 71.913601] [drm] clean up the vf2pf work item[ 71.915088] ------------[ cut here ]------------[ 71.915092] WARNING: CPU: 3 PID: 1079 at /tmp/amd.aFkFvSQl/amd/amdgpu/amdgpu_irq.c:641 amdgpu_irq_put+0xc6/0xe0 [amdgpu][ 71.915355] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_display_helper cec rc_core i2c_algo_bit video wmi binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common input_leds joydev serio_raw mac_hid qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 hid_generic crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel usbhid 8139too sha256_ssse3 sha1_ssse3 hid psmouse bochs i2c_i801 ahci drm_vram_helper libahci i2c_smbus lpc_ich drm_ttm_helper 8139cp mii ttm aesni_intel crypto_simd cryptd[ 71.915484] CPU: 3 PID: 1079 Comm: rmmod Tainted: G OE 6.8.0-87-generic #88~22.04.1-Ubuntu[ 71.915489] Hardware name: Red Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01/2014[ 71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0 [amdgpu][ 71.915768] Code: 75 84 b8 ea ff ff ff eb d4 44 89 ea 48 89 de 4c 89 e7 e8 fd fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b c7 <0f> 0b eb d4 b8 fe ff ff ff eb a8 e9 b7 3b 8a 00 66 2e 0f 1f 84 00[ 71.915771] RSP: 0018:ffffcf0800eafa30 EFLAGS: 00010246[ 71.915775] RAX: 0000000000000000 RBX: ffff891bda4b0668 RCX: 0000000000000000[ 71.915777] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 71.915779] RBP: ffffcf0800eafa50 R08: 0000000000000000 R09: 0000000000000000[ 71.915781] R10: 0000000000000000 R11: 0000000000000000 R12: ffff891bda480000[ 71.915782] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000[ 71.915792] FS: 000070cff87c4c40(0000) GS:ffff893abfb80000(0000) knlGS:0000000000000000[ 71.915795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 71.915797] CR2: 00005fa13073e478 CR3: 000000010d634006 CR4: 0000000000770ef0[ 71.915800] PKRU: 55555554[ 71.915802] Call Trace:[ 71.915805] [ 71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0 [amdgpu]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: chips-media: wave5: Fix PM runtime usage count underflowReplace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend() inthe remove path to properly pair with pm_runtime_use_autosuspend() fromprobe. This allows pm_runtime_disable() to handle reference count cleanupcorrectly regardless of current suspend state.The driver calls pm_runtime_put_sync() unconditionally in remove, but thedevice may already be suspended due to autosuspend configured in probe.When autosuspend has already suspended the device, the usage count is 0,and pm_runtime_put_sync() decrements it to -1.This causes the following warning on module unload: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow!
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: clear page->private in free_pages_prepare()Several subsystems (slub, shmem, ttm, etc.) use page->private but don'tclear it before freeing pages. When these pages are later allocated ashigh-order pages and split via split_page(), tail pages retain stalepage->private values.This causes a use-after-free in the swap subsystem. The swap code usespage->private to track swap count continuations, assuming freshlyallocated pages have page->private == 0. When stale values are present,swap_count_continued() incorrectly assumes the continuation list is validand iterates over uninitialized page->lru containing LIST_POISON values,causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860Fix this by clearing page->private in free_pages_prepare(), ensuring allfreed pages have clean state regardless of previous use.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc/tegra: pmc: Fix unsafe generic_handle_irq() callCurrently, when resuming from system suspend on Tegra platforms,the following warning is observed:WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8The warning occurs because generic_handle_irq() is being called froma non-interrupt context which is considered as unsafe.Fix this warning by deferring generic_handle_irq() call to an IRQ workwhich gets executed in hard IRQ context where generic_handle_irq()can be called safely.When PREEMPT_RT kernels are used, regular IRQ work (initialized withinit_irq_work) is deferred to run in per-CPU kthreads in preemptiblecontext rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARDvariant so that with PREEMPT_RT kernels, the IRQ work is processed inhardirq context instead of being deferred to a thread which is requiredfor calling generic_handle_irq().On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD()execute in IRQ context, so this change has no functional impact forstandard kernel configurations.[treding@nvidia.com: miscellaneous cleanups]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()dcn401_init_hw() assumes that update_bw_bounding_box() is valid whenentering the update path. However, the existing condition: ((!fams2_enable && update_bw_bounding_box) || freq_changed)does not guarantee this, as the freq_changed branch can evaluate to trueindependently of the callback pointer.This can result in calling update_bw_bounding_box() when it is NULL.Fix this by separating the update condition from the pointer checks andensuring the callback, dc->clk_mgr, and bw_params are validated beforeuse.Fixes the below:../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed 'dc->res_pool->funcs->update_bw_bounding_box' could be null (see line 362)(cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ipv6: ioam6: prevent schema length wraparound in trace fillioam6_fill_trace_data() stores the schema contribution to the tracelength in a u8. With bit 22 enabled and the largest schema payload,sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses theremaining-space check. __ioam6_fill_trace_data() then positions thewrite cursor without reserving the schema area but still copies the4-byte schema header and the full schema payload, overrunning the tracebuffer.Keep sclen in an unsigned int so the remaining-space check and the writecursor calculation both see the full schema length.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipa: fix event ring index not programmed for IPA v5.0+For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 toCH_C_CNTXT_1. The v5.0 register definition intended to define thisfield in the CH_C_CNTXT_1 fmask array but used the old identifier ofERINDEX instead of CH_ERINDEX.Without a valid event ring, GSI channels could never signal transfercompletions. This caused gsi_channel_trans_quiesce() to blockforever in wait_for_completion().At least for IPA v5.2 this resolves an issue seen where runtimesuspend, system suspend, and remoteproc stop all hanged forever. Italso meant the IPA data path was completely non functional.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: ptp: don't WARN when controlling PF is unavailableIn VFIO passthrough setups, it is possible to pass through only a PFwhich doesn't own the source timer. In that case the PTP controlling PF(adapter->ctrl_pf) is never initialized in the VM, so ice_get_ctrl_ptp()returns NULL and triggers WARN_ON() in ice_ptp_setup_pf().Since this is an expected behavior in that configuration, replaceWARN_ON() with an informational message and return -EOPNOTSUPP.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on file creation due to name hash collisionIf we attempt to create several files with names that result in the samehash, we have to pack them in same dir item and that has a limit inherentto the leaf size. However if we reach that limit, we trigger a transactionabort and turns the filesystem into RO mode. This allows for a malicioususer to disrupt a system, without the need to have administrationprivileges/capabilities.Reproducer: $ cat exploit-hash-collisions.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:_6dBJ_' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2:%2_am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGF_ZVr$ivrvhVgD@1u%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05L_ROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$_2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG_8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_:u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA--@WqWLIuX7o1S_SfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8_jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mC---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix undersized l_iclog_roundoff valuesIf the superblock doesn't list a log stripe unit, we set the incore logroundoff value to 512. This leads to corrupt logs and unmountablefilesystems in generic/617 on a disk with 4k physical sectors...XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1cXFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.XFS (sda1): failed to locate log tailXFS (sda1): log mount/recovery failed: error -74XFS (sda1): log mount failedXFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1cXFS (sda1): Ending clean mount...on the current xfsprogs for-next which has a broken mkfs. xfs_infoshows this...meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0...observe that the log section has sectsz=4096 sunit=0, which meansthat the roundoff factor is 512, not 4096 as you'd expect. We shouldfix mkfs not to generate broken filesystems, but anyone can fuzz theondisk superblock so we should be more cautious. I think the inadequatelogic predates commit a6a65fef5ef8d0, but that's clearly going torequire a different backport.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mctp: route: hold key->lock in mctp_flow_prepare_output()mctp_flow_prepare_output() checks key->dev and may callmctp_dev_set_key(), but it does not hold key->lock while doing so.mctp_dev_set_key() and mctp_dev_release_key() are annotated with__must_hold(&key->lock), so key->dev access is intended to beserialized by key->lock. The mctp_sendmsg() transmit path reachesmctp_flow_prepare_output() via mctp_local_output() -> mctp_dst_output()without holding key->lock, so the check-and-set sequence is racy.Example interleaving: CPU0 CPU1 ---- ---- mctp_flow_prepare_output(key, devA) if (!key->dev) // sees NULL mctp_flow_prepare_output( key, devB) if (!key->dev) // still NULL mctp_dev_set_key(devB, key) mctp_dev_hold(devB) key->dev = devB mctp_dev_set_key(devA, key) mctp_dev_hold(devA) key->dev = devA // overwrites devBNow both devA and devB references were acquired, but only the finalkey->dev value is tracked for release. One reference can be lost,causing a resource leak as mctp_dev_release_key() would only decreasethe reference on one dev.Fix by taking key->lock around the key->dev check andmctp_dev_set_key() call.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mctp: i2c: fix skb memory leak in receive pathWhen 'midev->allow_rx' is false, the newly allocated skb isn't consumedby netif_rx(), it needs to free the skb directly.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQXDP multi-buf programs can modify the layout of the XDP buffer when theprogram calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). Thereferenced commit in the fixes tag corrected the assumption in the mlx5driver that the XDP buffer layout doesn't change during a programexecution. However, this fix introduced another issue: the droppedfragments still need to be counted on the driver side to avoid pagefragment reference counting issues.The issue was discovered by the drivers/net/xdp.py selftest,more specifically the test_xdp_native_tx_mb:- The mlx5 driver allocates a page_pool page and initializes it with a frag counter of 64 (pp_ref_count=64) and the internal frag counter to 0.- The test sends one packet with no payload.- On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above.- The XDP program runs and calls bpf_xdp_pull_data() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pp_ref_count=63).- mlx5 device skips counting this fragment. Internal frag counter remains 0.- mlx5 releases all 64 fragments of the page but page pp_ref_count is 63 => negative reference counting error.Resulting splat during the test: WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_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:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...] Call Trace: mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70The problem applies for XDP_PASS as well which is handled in a differentcode path in the driver.This patch fixes the issue by doing page frag counting on all theoriginal XDP buffer fragments for all relevant XDP actions (XDP_TX ,XDP_REDIRECT and XDP_PASS). This is basically reverting to the originalcounting before the commit in the fixes tag.As frag_page is still pointing to the original tail, the nr_fragsparameter to xdp_update_skb_frags_info() needs to be calculatedin a different way to reflect the new nr_frags.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix deadlock between devlink lock and esw->wqesw->work_queue executes esw_functions_changed_event_handler ->esw_vfs_changed_event_handler and acquires the devlink lock..eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) ->mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked ->mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlockswhen esw_vfs_changed_event_handler executes.Fix that by no longer flushing the work to avoid the deadlock, and usinga generation counter to keep track of work relevance. This avoids an oldhandler manipulating an esw that has undergone one or more mode changes:- the counter is incremented in mlx5_eswitch_event_handler_unregister.- the counter is read and passed to the ephemeral mlx5_host_work struct.- the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on.- mlx5_eswitch_cleanup does the final draining before destroying the wq.No longer flushing the workqueue has the side effect of maybe no longercancelling pending vport_change_handler work items, but that's ok sincethose are disabled elsewhere:- mlx5_eswitch_disable_locked disables the vport eq notifier.- mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything.- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: return EISDIR on nfs3_proc_create if d_alias is a dirIf we found an alias through nfs3_do_create/nfs_add_or_obtain/d_splice_alias which happens to be a dir dentry, we don't returnany error, and simply forget about this alias, but the originaldentry we were adding and passed as parameter remains negative.This later causes an oops on nfs_atomic_open_v23/finish_open since wesupply a negative dentry to do_dentry_open.This has been observed running lustre-racer, where dirs and files arecreated/removed concurrently with the same name and O_EXCL is notused to open files (frequent file redirection).While d_splice_alias typically returns a directory alias or NULL, weexplicitly check d_is_dir() to ensure that we don't attempt to performfile operations (like finish_open) on a directory inode, which triggersthe observed oops.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Add NULL checks when resetting request and reply queuesThe driver encountered a crash during resource cleanup when the reply andrequest queues were NULL due to freed memory. This issue occurred when thecreation of reply or request queues failed, and the driver freed the memoryfirst, but attempted to mem set the content of the freed memory, leading toa system crash.Add NULL pointer checks for reply and request queues before accessing thereply/request memory during cleanup
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/gsp: drop WARN_ON in ACPI probesThese WARN_ONs seem to trigger a lot, and we don't seem to have aplan to fix them, so just drop them, as they are most likelyharmless.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: prevent infinite loops caused by the next valid being the sameWhen processing valid within the range [valid : pos), if valid cannotbe retrieved correctly, for example, if the retrieved valid value isalways the same, this can trigger a potential infinite loop, similarto the hung problem reported by syzbot [1].Adding a check for the valid value within the loop body, and terminatingthe loop and returning -EINVAL if the value is the same as the currentvalue, can prevent this.[1]INFO: task syz.4.21:6056 blocked for more than 143 seconds.Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_rbtree: check for partial overlaps in anonymous setsUserspace provides an optimized representation in case intervals areadjacent, where the end element is omitted.The existing partial overlap detection logic skips anonymous set checkson start elements for this reason.However, it is possible to add intervals that overlap to this anonymouswhere two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A CRestore the check on overlapping start elements to report an overlap.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: drop extent cache when splitting extent failsWhen the split extent fails, we might leave some extents still beingprocessed and return an error directly, which will result in staleextent entries remaining in the extent status tree. So drop all of theremaining potentially stale extents if the splitting fails.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: always update mdb_n_entries for vlan contextssyzbot triggered a warning[1] about the number of mdb entries in a context.It turned out that there are multiple ways to trigger that warning today(some got added during the years), the root cause of the problem is thatthe increase is done conditionally, and over the years these differentconditions increased so there were new ways to trigger the warning, that isto do a decrease which wasn't paired with a previous increase.For example one way to trigger it is with flush: $ ip l add br0 up type bridge vlan_filtering 1 mcast_snooping 1 $ ip l add dumdum up master br0 type dummy $ bridge mdb add dev br0 port dumdum grp 239.0.0.1 permanent vid 1 $ ip link set dev br0 down $ ip link set dev br0 type bridge mcast_vlan_snooping 1 ^^^^ this will enable snooping, but will not update mdb_n_entries because in __br_multicast_enable_port_ctx() we check !netif_running $ bridge mdb flush dev br0 ^^^ this will trigger the warning because it will delete the pg which we added above, which will try to decrease mdb_n_entriesFix the problem by removing the conditional increase and always keep thecount up-to-date while the vlan exists. In order to do that we have tofirst initialize it on port-vlan context creation, and then always increaseor decrease the value regardless of mcast options. To keep the currentbehaviour we have to enforce the mdb limit only if the context is port's orif the port-vlan's mcast snooping is enabled.[1] ------------[ cut here ]------------ n == 0 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825, CPU#0: syz.4.4607/22043 Modules linked in: CPU: 0 UID: 0 PID: 22043 Comm: syz.4.4607 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline] RIP: 0010:br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline] RIP: 0010:br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825 Code: 41 5f 5d e9 04 7a 48 f7 e8 3f 73 5c f7 90 0f 0b 90 e9 cf fd ff ff e8 31 73 5c f7 90 0f 0b 90 e9 16 fd ff ff e8 23 73 5c f7 90 <0f> 0b 90 e9 60 fd ff ff e8 15 73 5c f7 eb 05 e8 0e 73 5c f7 48 8b RSP: 0018:ffffc9000c207220 EFLAGS: 00010293 RAX: ffffffff8a68042d RBX: ffff88807c6f1800 RCX: ffff888066e90000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff888066e90000 R09: 000000000000000c R10: 000000000000000c R11: 0000000000000000 R12: ffff8880303ef800 R13: dffffc0000000000 R14: ffff888050eb11c4 R15: 1ffff1100a1d6238 FS: 00007fa45921b6c0(0000) GS:ffff8881256f5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa4591f9ff8 CR3: 0000000081df2000 CR4: 00000000003526f0 Call Trace: br_mdb_flush_pgs net/bridge/br_mdb.c:1525 [inline] br_mdb_flush net/bridge/br_mdb.c:1544 [inline] br_mdb_del_bulk+0x5e2/0xb20 net/bridge/br_mdb.c:1561 rtnl_mdb_del+0x48a/0x640 net/core/rtnetlink.c:-1 rtnetlink_rcv_msg+0x77e/0xbe0 net/core/rtnetlink.c:6967 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:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socke---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fat: avoid parent link count underflow in rmdirCorrupted FAT images can leave a directory inode with an incorrecti_nlink (e.g. 2 even though subdirectories exist). rmdir thenunconditionally calls drop_nlink(dir) and can drive i_nlink to 0,triggering the WARN_ON in drop_nlink().Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop theparent link count when it is at least 3, otherwise report a filesystemerror.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: do not keep dest_dst if dev is going downThere is race between the netdev notifier ip_vs_dst_event()and the code that caches dst with dev that is going down.As the FIB can be notified for the closed device after ourhandler finishes, it is possible valid route to be returnedand cached resuling in a leaked dev reference until the destis not removed.To prevent new dest_dst to be attached to dest just after thehandler dropped the old one, add a netif_running() checkto make sure the notifier handler is not currently runningfor device that is closing.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix dirtyclusters double decrement on fs shutdownfstests test generic/388 occasionally reproduces a warning inext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]Tracing the failure shows that the warning fires due to ans_dirtyclusters_counter value of -1. IOW, this appears to be aspurious decrement as opposed to some sort of leak. Further tracingof the dirty cluster count deltas and an LLM scan of the resultingoutput identified the cause as a double decrement in the error pathbetween ext4_mb_mark_diskspace_used() and the callerext4_mb_new_blocks().First, note that generic/388 is a shutdown vs. fsstress test and soproduces a random set of operations and shutdown injections. In theproblematic case, the shutdown triggers an error return from theext4_handle_dirty_metadata() call(s) made fromext4_mb_mark_context(). The changed value is non-zero at this point,so ext4_mb_mark_diskspace_used() does not exit after the errorbubbles up from ext4_mb_mark_context(). Instead, the formerdecrements both cluster counters and returns the error up toext4_mb_new_blocks(). The latter falls into the !ar->len out pathwhich decrements the dirty clusters counter a second time, creatingthe inconsistency.To avoid this problem and simplify ownership of the clusterreservation in this codepath, lift the counter reduction to a singleplace in the caller. This makes it more clear thatext4_mb_new_blocks() is responsible for acquiring clusterreservation (via ext4_claim_free_clusters()) in the !delalloc caseas well as releasing it, regardless of whether it ends up consumedor returned due to failure.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error pathsThere are two places where ksmbd_vfs_kern_path_end_removing() needs to becalled in order to balance what the corresponding successful call toksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks andput the taken references. Otherwise there might be potential deadlocksand unbalanced locks which are caught like:BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014Workqueue: ksmbd-io handle_ksmbd_workCall Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mctp: ensure our nlmsg responses are initialisedSyed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) fromDEVCORE Research Team working with Trend Micro Zero Day Initiativereport that a RTM_GETNEIGH will return uninitalised data in the padbytes of the ndmsg data.Ensure we're initialising the netlink data to zero, in the link, addrand neigh response messages.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix oops when split header is enabledFor GMAC4, when split header is enabled, in some rare cases, thehardware does not fill buf2 of the first descriptor with payload.Thus we cannot assume buf2 is always fully filled if it is notthe last descriptor. Otherwise, the length of buf2 of the seconddescriptor will be calculated wrong and cause an oops:Unable to handle kernel paging request at virtual address ffff00019246bfc0...x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000Call trace: dcache_inval_poc+0x28/0x58 (P) dma_direct_sync_single_for_cpu+0x38/0x6c __dma_sync_single_for_cpu+0x34/0x6c stmmac_napi_poll_rx+0x8f0/0xb60 __napi_poll.constprop.0+0x30/0x144 net_rx_action+0x160/0x274 handle_softirqs+0x1b8/0x1fc...To fix this, the PL bit-field in RDES3 register is used for alldescriptors, whether it is the last descriptor or not.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix memory leak in ext4_ext_shift_extents()In ext4_ext_shift_extents(), if the extent is NULL in the while loop, thefunction returns immediately without releasing the path obtained viaext4_find_extent(), leading to a memory leak.Fix this by jumping to the out label to ensure the path is properlyreleased.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix rcu_read_unlock() deadloop due to softirqCommit 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in__rcu_read_unlock()") removes the recursion-protection code from__rcu_read_unlock(). Therefore, we could invoke the deadloop inraise_softirq_irqoff() with ftrace enabled as follows:WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0+0x172/0x180Modules linked in: my_irq_work(O)CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.18.0-rc7-dirty #23 PREEMPT(full)Tainted: [O]=OOT_MODULEHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:__ftrace_trace_stack.constprop.0+0x172/0x180RSP: 0018:ffffc900000034a8 EFLAGS: 00010002RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000RDX: 0000000000000003 RSI: ffffffff826d7b87 RDI: ffffffff826e9329RBP: 0000000000090009 R08: 0000000000000005 R09: ffffffff82afbc4cR10: 0000000000000008 R11: 0000000000011d7a R12: 0000000000000000R13: ffff888003874100 R14: 0000000000000003 R15: ffff8880038c1054FS: 0000000000000000(0000) GS:ffff8880fa8ea000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055b31fa7f540 CR3: 00000000078f4005 CR4: 0000000000770ef0PKRU: 55555554Call Trace: trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 __is_insn_slot_addr+0x54/0x70 kernel_text_address+0x48/0xc0 __kernel_text_address+0xd/0x40 unwind_get_return_address+0x1e/0x40 arch_stack_walk+0x9c/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 __raise_softirq_irqoff+0x61/0x80 __flush_smp_call_function_queue+0x115/0x420 __sysvec_call_function_single+0x17/0xb0 sysvec_call_function_single+0x8c/0xc0 Commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work")fixed the infinite loop in rcu_read_unlock_special() for IRQ work bysetting a flag before calling irq_work_queue_on(). We fix this issue bysetting the same flag before calling raise_softirq_irqoff() and rename theflag to defer_qs_pending for more common.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: return error when node already exists in hfs_bnode_createWhen hfs_bnode_create() finds that a node is already hashed (which shouldnot happen in normal operation), it currently returns the existing nodewithout incrementing its reference count. This causes a reference countinconsistency that leads to a kernel panic when the node is later freedin hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt))This scenario can occur when hfs_bmap_alloc() attempts to allocate a nodethat is already in use (e.g., when node 0's bitmap bit is incorrectlyunset), or due to filesystem corruption.Returning an existing node from a create path is not normal operation.Fix this by returning ERR_PTR(-EEXIST) instead of the node when it'salready hashed. This properly signals the error condition to callers,which already check for IS_ERR() return values.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ublk: Validate SQE128 flag before accessing the cmdublk_ctrl_cmd_dump() accesses (header *)sqe->cmd beforeIO_URING_F_SQE128 flag check. This could cause out of boundary memoryaccess.Move the SQE128 flag check earlier in ublk_ctrl_uring_cmd() to return-EINVAL immediately if the flag is not set.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix gss_auth kref leak in gss_alloc_msg error pathCommit 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") addeda kref_get(&gss_auth->kref) call to balance the gss_put_auth() donein gss_release_msg(), but forgot to add a corresponding kref_put()on the error path when kstrdup_const() fails.If service_name is non-NULL and kstrdup_const() fails, the functionjumps to err_put_pipe_version which calls put_pipe_version() andkfree(gss_msg), but never releases the gss_auth reference. This leadsto a kref leak where the gss_auth structure is never freed.Add a forward declaration for gss_free_callback() and call kref_put()in the err_put_pipe_version error path to properly release thereference taken earlier.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix invalid deref of rawdata when export_binary is unsetIf the export_binary parameter is disabled on runtime, profiles thatwere loaded before that will still have their rawdata stored inapparmorfs, with a symbolic link to the rawdata on the policydirectory. When one of those profiles are replaced, the rawdata is setto NULL, but when trying to resolve the symbolic links to rawdata forthat profile, it will try to dereference profile->rawdata->name whenprofile->rawdata is now NULL causing an oops. Fix it by checking ifrawdata is set.[ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088[ 168.657420] #PF: supervisor read access in kernel mode[ 168.660619] #PF: error_code(0x0000) - not-present page[ 168.663613] PGD 0 P4D 0[ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI[ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary)[ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330[ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8[ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282[ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158[ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80[ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000[ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80[ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0[ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000[ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0[ 168.701696] Call Trace:[ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30[ 168.704145] vfs_readlink+0xd4/0x160[ 168.705152] do_readlinkat+0x114/0x180[ 168.706214] __x64_sys_readlink+0x1e/0x30[ 168.708653] x64_sys_call+0x1d77/0x26b0[ 168.709525] do_syscall_64+0x81/0x500[ 168.710348] ? do_statx+0x72/0xb0[ 168.711109] ? putname+0x3e/0x80[ 168.711845] ? __x64_sys_statx+0xb7/0x100[ 168.712711] ? x64_sys_call+0x10fc/0x26b0[ 168.713577] ? do_syscall_64+0xbf/0x500[ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0[ 168.715404] ? irqentry_exit+0xb2/0x740[ 168.716359] ? exc_page_fault+0x90/0x1b0[ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpuidle: Skip governor when only one idle state is availableOn certain platforms (PowerNV systems without a power-mgt DT node),cpuidle may register only a single idle state. In cases where thatsingle state is a polling state (state 0), the ladder governor mayincorrectly treat state 1 as the first usable state and pass anout-of-bounds index. This can lead to a NULL enter callback beinginvoked, ultimately resulting in a system crash.[ 13.342636] cpuidle-powernv : Only Snooze is available[ 13.351854] Faulting instruction address: 0x00000000[ 13.376489] NIP [0000000000000000] 0x0[ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668Fix this by adding a bail-out in cpuidle_select() that returns state 0directly when state_count <= 1, bypassing the governor and keeping thetick running.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not foundIf btrfs_search_slot_for_read() returns 1, it means we did not find anykey greater than or equals to the key we asked for, meaning we havereached the end of the tree and therefore the path is not valid. Ifthis happens we need to break out of the loop and stop, instead ofcontinuing and accessing an invalid path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/cio: Fix device lifecycle handling in css_alloc_subchannel()`css_alloc_subchannel()` calls `device_initialize()` before setting upthe DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails,the error path frees the subchannel structure directly, bypassingthe device model reference counting.Once `device_initialize()` has been called, the embedded struct devicemust be released via `put_device()`, allowing the release callback tofree the container structure.Fix the error path by dropping the initial device reference with`put_device()` instead of calling `kfree()` directly.This ensures correct device lifetime handling and avoids potentialuse-after-free or double-free issues.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: never defer requests during idmap lookupDuring v4 request compound arg decoding, some ops (e.g. SETATTR)can trigger idmap lookup upcalls. When those upcall responses getdelayed beyond the allowed time limit, cache_check() will mark therequest for deferral and cause it to be dropped.This prevents nfs4svc_encode_compoundres from being executed, andthus the session slot flag NFSD4_SLOT_INUSE never gets cleared.Subsequent client requests will fail with NFSERR_JUKEBOX, giventhat the slot will be marked as in-use, making the SEQUENCE opfail.Fix this by making sure that the RQ_USEDEFERRAL flag is alwaysclear during nfs4svc_decode_compoundargs(), since no v4 requestshould ever be deferred.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/OWhen allocating blocks during within-EOF DIO and writeback withdioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split anexisting large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT wasset when calling ext4_split_convert_extents(), which may potentiallyresult in stale data issues.Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this rangeFirst, ext4_iomap_alloc() call ext4_map_blocks() withEXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT andEXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent andcall ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and theabove flags set.Then, ext4_split_convert_extents() calls ext4_split_extent() withEXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2flags set, and it calls ext4_split_extent_at() to split the second halfwith EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUTand EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()failed to insert extent since a temporary lack -ENOSPC. It zeroes outthe first half but convert the entire on-disk extent to written sincethe EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwrittenin the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status treeFinally, if the DIO failed to write data to the disk, the stale data inthe second half will be exposed once the cached extent entry is gone.Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splittingan unwritten extent before submitting I/O, and makeext4_split_convert_extents() to zero out the entire extent rangeto zero for this case, and also mark the extent in the extent statustree for consistency.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncsfields written by the CPU from vmcb02 to the cached vmcb12. This isbecause the cached vmcb12 is used as the authoritative copy of some ofthe controls, and is the payload when saving/restoring nested state.int_state is also written by the CPU, specifically bit 0 (i.e.SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd tocached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATEpreceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadowwould be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwriteswhat KVM_SET_NESTED_STATE restored in int_state).However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, aninterrupt shadow would be restored into vmcb01 instead of vmcb02. Thiswould mostly be benign for L1 (delays an interrupt), but not for L2. ForL2, the vCPU could hang (e.g. if a wakeup interrupt is delivered beforea HLT that should have been in an interrupt shadow).Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02()to avoid this problem. With that, KVM_SET_NESTED_STATE restores thecorrect interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows itwould overwrite it with the same value.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmasm: fix OOB reads in command_file_write due to missing size checksThe command_file_write() handler allocates a kernel buffer of exactlycount bytes and copies user data into it, but does not validate thebuffer against the dot command protocol before passing it toget_dot_command_size() and get_dot_command_timeout().Since both the allocation size (count) and the header fields (command_size,data_size) are independently user-controlled, an attacker can causeget_dot_command_size() to return a value exceeding the allocation,triggering OOB reads in get_dot_command_timeout() and an out-of-boundsmemcpy_toio() that leaks kernel heap memory to the service processor.Fix with two guards: reject writes smaller than sizeof(structdot_command_header) before allocation, then after copying user datareject commands where the buffer is smaller than the total size declaredby the header (sizeof(header) + command_size + data_size). This ensuresall subsequent header and payload field accesses stay within the buffer.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sd: fix missing put_disk() when device_add(&disk_dev) failsIf device_add(&sdkp->disk_dev) fails, put_device() runsscsi_disk_release(), which frees the scsi_disk but leaves the gendiskreferenced. The device_add_disk() error path in sd_probe() callsput_disk(gd); call put_disk(gd) here to mirror that cleanup.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix potential UAF after skb_unshare() failureIf skb_unshare() fails to unshare a packet due to allocation failure inrxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread())will be NULL'd out. This will likely cause the call totrace_rxrpc_rx_done() to oops.Fix this by moving the unsharing down to where rxrpc_input_call_event()calls rxrpc_input_call_packet(). There are a number of places prior tothat where we ignore DATA packets for a variety of reasons (such as thecall already being complete) for which an unshare is then avoided.And with that, rxrpc_input_packet() doesn't need to take a pointer to thepointer to the packet, so change that to just a pointer.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()Some crafted images can have illegal (!partial_decoding &&m_llen < m_plen) extents, and the LZ4 inplace decompression pathcan be wrongly hit, but it cannot handle (outpages < inpages)properly: "outpages - inpages" wraps to a large value andthe subsequent rq->out[] access reads past the decompressed_pagesarray.However, such crafted cases can correctly result in a corruptionreport in the normal LZ4 non-inplace path.Let's add an additional check to fix this for backporting.Reproducible image (base64-encoded gzipped blob):H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+gdilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9iPNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1wywAAAAAAAADwu14ATsEYtgBQAAA=$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt$ dd if=/mnt/data of=/dev/null bs=4096 count=1
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix conn-level packet handling to unshare RESPONSE packetsThe security operations that verify the RESPONSE packets decrypt bits of itin place - however, the sk_buff may be shared with a packet sniffer, whichwould lead to the sniffer seeing an apparently corrupt packet (actuallydecrypted).Fix this by handing a copy of the packet off to the specific securityhandler if the packet was cloned.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: ns: Limit the total number of nodesCurrently, the nameserver doesn't limit the number of nodes it handles.This can be an attack vector if a malicious client starts registeringrandom nodes, leading to memory exhaustion.Hence, limit the maximum number of nodes to 64. Note that, limit of 64 ischosen based on the current platform requirements. If requirement changesin the future, this limit can be increased.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix a resource leak in xfs_alloc_buftarg()In the error path, call fs_put_dax() to drop the DAXdevice reference.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Add missing save/restore handling of LBR MSRsMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated byKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. Sosave/restore is completely broken.Fix it by adding the MSRs to msrs_to_save_base, and allowing writes toLBR MSRs from userspace only (as they are read-only MSRs) if LBRvirtualization is enabled. Additionally, to correctly restore L1's LBRswhile L2 is running, make sure the LBRs are copied from the capturedVMCB01 save area in svm_copy_vmrun_state().Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn'treported as an MSR to save/restore.Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM alreadyhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM:Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph theunsupported userspace write into a nop).[sean: guard with lbrv checks, massage changelog]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: call sk_data_ready() after listener migrationWhen inet_csk_listen_stop() migrates an established child socket froma closing listener to another socket in the same SO_REUSEPORT group,the target listener gets a new accept-queue entry viainet_csk_reqsk_queue_add(), but that path never notifies the targetlistener's waiters. A nonblocking accept() still works because itchecks the queue directly, but poll()/epoll_wait() waiters andblocking accept() callers can also remain asleep indefinitely.Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migrationin inet_csk_listen_stop().However, after inet_csk_reqsk_queue_add() succeeds, the ref acquiredin reuseport_migrate_sock() is effectively transferred tonreq->rsk_listener. Another CPU can then dequeue nreq via accept()or listener shutdown, hit reqsk_put(), and drop that listener ref.Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which alsocovers the existing sock_net(nsk) access in that path.The reqsk_timer_handler() path does not need the same changes for tworeasons: half-open requests become readable only after the final ACK,where tcp_child_process() already wakes the listener; and once nreq isvisible via inet_ehash_insert(), the success path no longer touchesnsk directly.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO readwhen the queue reader or writer index from hardware exceedsREMOTE_QUEUE_SIZE (60).A compromised service processor can trigger this by writing anout-of-range value to the reader or writer MMIO register beforeasserting an interrupt. Since writer is re-read from hardware onevery loop iteration, it can also be set to an out-of-range valueafter the loop has already started.The root cause is that get_queue_reader() and get_queue_writer() returnraw readl() values that are passed directly into get_queue_entry(),which computes: queue_begin + reader * sizeof(struct remote_input)with no bounds check. This unchecked MMIO address is then passed tomemcpy_fromio(), reading 8 bytes from unintended device registers.For sufficiently large values the address falls outside the PCI BARmapping entirely, triggering a machine check exception.Fix by checking both indices against REMOTE_QUEUE_SIZE at the top ofthe loop body, before any call to get_queue_entry(). On an out-of-rangevalue, reset the reader register to 0 via set_queue_reader() beforebreaking, so that normal queue operation can resume if the corruptedhardware state is transient.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: ns: Limit the maximum number of lookupsCurrent code does no bound checking on the number of lookups a client canperform. Though the code restricts the lookups to local clients, there isstill a possibility of a malicious local client sending a flood ofNEW_LOOKUP messages over the same socket.Fix this issue by limiting the maximum number of lookups to 64 globally.Since the nameserver allows only atmost one local observer, this globallookup count will ensure that the lookups stay within the limit.Note that, limit of 64 is chosen based on the current platformrequirements. If requirement changes in the future, this limit can beincreased.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: avoid early lgr access in smc_clc_wait_msgA CLC decline can be received while the handshake is still in an earlystage, before the connection has been associated with a link group.The decline handling in smc_clc_wait_msg() updates link-group level syncstate for first-contact declines, but that state only exists after linkgroup setup has completed. Guard the link-group update accordingly andkeep the per-socket peer diagnosis handling unchanged.This preserves the existing sync_err handling for established link-groupcontexts and avoids touching link-group state before it is available.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: algif_aead - snapshot IV for async AEAD requestsAF_ALG AEAD AIO requests currently use the socket-wide IV buffer duringrequest processing. For async requests, later socket activity canupdate that shared state before the original request has fullycompleted, which can lead to inconsistent IV handling.Snapshot the IV into per-request storage when preparing the AEADrequest, so in-flight operations no longer depend on mutable socketstate.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXITIf loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit()returns an error code that is ignored by most callers, and continues torun L1 with corrupted state. A sane recovery is not possible in thiscase, and HW behavior is to cause a shutdown. Inject a triple faultinstead, and do not return early from nested_svm_vmexit(). Continuecleaning up the vCPU state (e.g. clear pending exceptions), to handlethe failure as gracefully as possible.From the APM: Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context: ... if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUNRemove the return value of nested_svm_vmexit(), which is mostlyunchecked anyway.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/cdx: Fix NULL pointer dereference in interrupt trigger pathAdd validation to ensure MSI is configured before accessing cdx_irqsarray in vfio_cdx_set_msi_trigger(). Without this check, userspacecan trigger a NULL pointer dereference by calling VFIO_DEVICE_SET_IRQSwith VFIO_IRQ_SET_DATA_BOOL or VFIO_IRQ_SET_DATA_NONE flags beforeever setting up interrupts via VFIO_IRQ_SET_DATA_EVENTFD.The vfio_cdx_msi_enable() function allocates the cdx_irqs array andsets config_msi to 1 only when called through the EVENTFD path. Thetrigger loop (for DATA_BOOL/DATA_NONE) assumed this had already beendone, but there was no enforcement of this call ordering.This matches the protection used in the PCI VFIO driver wherevfio_pci_set_msi_trigger() checks irq_is() before the trigger loop.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/cdx: Serialize VFIO_DEVICE_SET_IRQS with a per-device mutexvfio_cdx_set_msi_trigger() reads vdev->config_msi and operates on thevdev->cdx_irqs array based on its value, but provides no serializationagainst concurrent VFIO_DEVICE_SET_IRQS ioctls. Two callers can racesuch that one observes config_msi as set while another clears it andfrees cdx_irqs via vfio_cdx_msi_disable(), resulting in a use-after-freeof the cdx_irqs array.Add a cdx_irqs_lock mutex to struct vfio_cdx_device and acquire it invfio_cdx_set_msi_trigger(), which is the single chokepoint throughwhich all updates to config_msi, cdx_irqs, and msi_count flow, coveringboth the ioctl path and the close-device cleanup path. This keeps thetest of config_msi atomic with the subsequent enable, disable, ortrigger operations.Drop the pre-call !cdx_irqs test from vfio_cdx_irqs_cleanup() as partof this change: the optimization it provided is redundant with the!config_msi early-return inside vfio_cdx_msi_disable(), and leaving thetest in place would be an unsynchronized read of state the new lock ismeant to protect.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: ns: Free the node during ctrl_cmd_bye()A node sends the BYE packet when it is about to go down. So the nameservershould advertise the removal of the node to all remote and local observersand free the node finally. But currently, the nameserver doesn't free thenode memory even after processing the BYE packet. This causes the nodememory to leak.Hence, remove the node from Xarray list and free the node memory duringboth success and failure case of ctrl_cmd_bye().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inotify: fix watch count leak when fsnotify_add_inode_mark_locked() failsWhen fsnotify_add_inode_mark_locked() fails in inotify_new_watch(),the error path calls inotify_remove_from_idr() but does not calldec_inotify_watches() to undo the preceding inc_inotify_watches().This leaks a watch count, and repeated failures can exhaust themax_user_watches limit with -ENOSPC even when no watches are active.Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespacelimits"), the watch count was incremented after fsnotify_add_mark_locked()succeeded, so this path was not affected. The conversion movedinc_inotify_watches() before the mark insertion without adding thecorresponding rollback.Add the missing dec_inotify_watches() call in the error path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi:ssif: Clean up kthread on errorsIf an error occurs after the ssif kthread is created, but before themain IPMI code starts the ssif interface, the ssif kthread will notbe stopped.So make sure the kthread is stopped on an error condition if it isrunning.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()The commit c8e008b60492 ("ext4: ignore xattrs past end")introduced a refcount leak in when block_csum is false.ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() toget iloc.bh, but never releases it with brelse().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix deadlock with check operation and nowait requestsWhen an array check is running it will raise the barrier at which pointnormal requests will become blocked and increment the nr_pending value tosignal there is work pending inside of wait_barrier(). NOWAIT requestsdo not block and so will return immediately with an error, and additionallydo not increment nr_pending in wait_barrier(). Upstream change commit43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added acall to raid_end_bio_io() to fix a memory leak when NOWAIT requests hitthis condition. raid_end_bio_io() eventually calls allow_barrier() andit will unconditionally do an atomic_dec_and_test(&conf->nr_pending) eventhough the corresponding increment on nr_pending didn't happen in theNOWAIT case.This can be easily seen by starting a check operation while an applicationis doing nowait IO on the same array. This results in a deadlocked statedue to nr_pending value underflowing and so the md resync thread gets stuckwaiting for nr_pending to == 0.Output of r10conf state of the array when we hit this condition:crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0,Example of md_sync thread stuck waiting on raise_barrier() and otherrequests stuck in wait_barrier():md1_resync[<0>] raise_barrier+0xce/0x1c0[<0>] raid10_sync_request+0x1ca/0x1ed0[<0>] md_do_sync+0x779/0x1110[<0>] md_thread+0x90/0x160[<0>] kthread+0xbe/0xf0[<0>] ret_from_fork+0x34/0x50[<0>] ret_from_fork_asm+0x1a/0x30kworker/u1040:2+flush-253:4[<0>] wait_barrier+0x1de/0x220[<0>] regular_request_wait+0x30/0x180[<0>] raid10_make_request+0x261/0x1000[<0>] md_handle_request+0x13b/0x230[<0>] __submit_bio+0x107/0x1f0[<0>] submit_bio_noacct_nocheck+0x16f/0x390[<0>] ext4_io_submit+0x24/0x40[<0>] ext4_do_writepages+0x254/0xc80[<0>] ext4_writepages+0x84/0x120[<0>] do_writepages+0x7a/0x260[<0>] __writeback_single_inode+0x3d/0x300[<0>] writeback_sb_inodes+0x1dd/0x470[<0>] __writeback_inodes_wb+0x4c/0xe0[<0>] wb_writeback+0x18b/0x2d0[<0>] wb_workfn+0x2a1/0x400[<0>] process_one_work+0x149/0x330[<0>] worker_thread+0x2d2/0x410[<0>] kthread+0xbe/0xf0[<0>] ret_from_fork+0x34/0x50[<0>] ret_from_fork_asm+0x1a/0x30
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix soft lockup in retry_aligned_read()When retry_aligned_read() encounters an overlapped stripe, it releasesthe stripe via raid5_release_stripe() which puts it on the locklessreleased_stripes llist. In the next raid5d loop iteration,release_stripe_list() drains the stripe onto handle_list (sinceSTRIPE_HANDLE is set by the original IO), but retry_aligned_read()runs before handle_active_stripes() and removes the stripe fromhandle_list via find_get_stripe() -> list_del_init(). This preventshandle_stripe() from ever processing the stripe to resolve theoverlap, causing an infinite loop and soft lockup.Fix this by using __release_stripe() with temp_inactive_list insteadof raid5_release_stripe() in the failure path, so the stripe does notgo through the released_stripes llist. This allows raid5d to break outof its loop, and the overlap will be resolved when the stripe iseventually processed by handle_stripe().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: fix MR cleanup on copy error__rds_rdma_map() hands sg/pages ownership to the transport afterget_mr() succeeds. If copying the generated cookie back to user spacefails after that point, the error path must not free those resourcesagain before dropping the MR reference.Remove the duplicate unpin/free from the put_user() failure branch sothat MR teardown is handled only through the existing final cleanuppath.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: fix overlayfs mmap() and mprotect() access checksThe existing SELinux security model for overlayfs is to allow access ifthe current task is able to access the top level file (the "user" file)and the mounter's credentials are sufficient to access the lowerlevel file (the "backing" file). Unfortunately, the current code doesnot properly enforce these access controls for both mmap() and mprotect()operations on overlayfs filesystems.This patch makes use of the newly created security_mmap_backing_file()LSM hook to provide the missing backing file enforcement for mmap()operations, and leverages the backing file API and new LSM blob toprovide the necessary information to properly enforce the mprotect()access controls.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Always use NextRIP as vmcb02's NextRIP after first L2 VMRUNFor guests with NRIPS disabled, L1 does not provide NextRIP when runningan L2 with an injected soft interrupt, instead it advances the current RIPbefore running it. KVM uses the current RIP as the NextRIP in vmcb02 toemulate a CPU without NRIPS.However, after L2 runs the first time, NextRIP will be updated by the CPUand/or KVM, and the current RIP is no longer the correct value to use invmcb02. Hence, after save/restore, use the current RIP if and only if anested run is pending, otherwise use NextRIP. Give soft_int_next_rip thesame treatment, as it's the same logic, just for a narrower use case.[sean: give soft_int_next_rip the same treatment]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmasm: fix heap over-read in ibmasm_send_i2o_message()The ibmasm_send_i2o_message() function uses get_dot_command_size() tocompute the byte count for memcpy_toio(), but this value is derived fromuser-controlled fields in the dot_command_header (command_size: u8,data_size: u16) and is never validated against the actual allocation size.A root user can write a small buffer with inflated header fields, causingmemcpy_toio() to read up to ~65 KB past the end of the allocation intoadjacent kernel heap, which is then forwarded to the service processorover MMIO.Silently clamping the copy size is not sufficient: if the header fieldsclaim a larger size than the buffer, the SP receives a dot command whoseown header is inconsistent with the I2O message length, which can causethe SP to desynchronize. Reject such commands outright by returningfailure.Validate command_size before calling get_mfa_inbound() to avoid leakingan I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardwareframe from the controller's free pool, and returning without acorresponding set_mfa_inbound() call would permanently exhaust it.Additionally, clamp command_size to I2O_COMMAND_SIZE before thememcpy_toio() so the MMIO write stays within the I2O message frame,consistent with the clamping already performed by outgoing_message_size()for the header field.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_infoHold state of deferred I/O in struct fb_deferred_io_state. Allocate aninstance as part of initializing deferred I/O and remove it only afterthe final mapping has been closed. If the fb_info and the containeddeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.infoto invalidate the mapping. Any access will then result in a SIGBUSsignal.Fixes a long-standing problem, where a device hot-unplug happens whileuser space still has an active mapping of the graphics memory. The hot-unplug frees the instance of struct fb_info. Accessing the memory willoperate on undefined state.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix num_ops off-by-one when crypto allocation failsmove_dirty_folio_in_page_array() may fail if the file is encrypted, thedirty folio is not the first in the batch, and it fails to allocate abounce buffer to hold the ciphertext. When that happens,ceph_process_folio_batch() simply redirties the folio and flushes thecurrent batch -- it can retry that folio in a future batch.However, if this failed folio is not contiguous with the last folio thatdid make it into the batch, then ceph_process_folio_batch() has alreadyincremented `ceph_wbc->num_ops`; because it doesn't follow through andadd the discontiguous folio to the array, ceph_submit_write() -- whichexpects that `ceph_wbc->num_ops` accurately reflects the number ofcontiguous ranges (and therefore the required number of "write extent"ops) in the writeback -- will panic the kernel: BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops);This issue can be reproduced on affected kernels by writing tofscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeatpattern (total filesize should not matter) and gradually increasing thesystem's memory pressure until a bounce buffer allocation fails.Fix this crash by decrementing `ceph_wbc->num_ops` back to the correctvalue when move_dirty_folio_in_page_array() fails, but the folio alreadystarted counting a new (i.e. still-empty) extent.The defect corrected by this patch has existed since 2022 (see first`Fixes:`), but another bug blocked multi-folio encrypted writeback untilrecently (see second `Fixes:`). The second commit made it into 6.18.16,6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patchtherefore fixes a regression (panic) introduced by cac190c7674f.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()The mwifiex_adapter_cleanup() function uses timer_delete()(non-synchronous) for the wakeup_timer before the adapter structure isfreed. This is incorrect because timer_delete() does not wait for anyrunning timer callback to complete.If the wakeup_timer callback (wakeup_timer_fn) is executing whenmwifiex_adapter_cleanup() is called, the callback will continue toaccess adapter fields (adapter->hw_status, adapter->if_ops.card_reset,etc.) which may be freed by mwifiex_free_adapter() called later in themwifiex_remove_card() path.Use timer_delete_sync() instead to ensure any running timer callback hascompleted before returning.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: add buffer boundary checks to run_unpack()run_unpack() checks `run_buf < run_last` at the top of the while loopbut then reads size_size and offset_size bytes via run_unpack_s64()without verifying they fit within the remaining buffer. A crafted NTFSimage with truncated run data in an MFT attribute triggers an OOB heapread of up to 15 bytes when the filesystem is mounted.Add boundary checks before each run_unpack_s64() call to ensure thedeclared field size does not exceed the remaining buffer.Found by fuzzing with a source-patched harness (LibAFL + QEMU).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix the out-of-bounds nameoff handling for trailing direntsCurrently we already have boundary-checks for nameoffs, but the trailingdirents are special since the namelens are calculated with strnlen()with unchecked nameoffs.If a crafted EROFS has a trailing dirent with nameoff >= maxsize,maxsize - nameoff can underflow, causing strnlen() to read past thedirectory block.nameoff0 should also be verified to be a multiple of`sizeof(struct erofs_dirent)` as well [1].[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rbd: fix null-ptr-deref when device_add_disk() failsdo_rbd_add() publishes the device with device_add() before callingdevice_add_disk(). If device_add_disk() fails after device_add()succeeds, the error path calls rbd_free_disk() directly and then laterfalls through to rbd_dev_device_release(), which calls rbd_free_disk()again. This double teardown can leave blk-mq cleanup operating oninvalid state and trigger a null-ptr-deref in__blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set().Fix this by following the normal remove ordering: call device_del()before rbd_dev_device_release() when device_add_disk() fails afterdevice_add(). That keeps the teardown sequence consistent and avoidsre-entering disk cleanup through the wrong path.The bug was first flagged by an experimental analysis tool we aredeveloping for kernel memory-management bugs while analyzingv6.13-rc1. The tool is still under development and is not yet publiclyavailable.We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducerconfines failslab injections to the __add_disk() range and injectsfail-nth while mapping an RBD image through/sys/bus/rbd/add_single_major.On the unpatched kernel, fail-nth=4 reliably triggered the fault: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240 Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 PKRU: 55555554 Call Trace: blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ? __pfx_do_rbd_add+0x10/0x10 ? lock_acquire+0x18c/0x300 ? find_held_lock+0x2b/0x80 ? sysfs_file_kobj+0xb6/0x1b0 ? __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ? expand_files+0x51f/0x850 ? __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ? __pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0fbea15907 Code: 10 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 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 With this fix applied, rerunning the reproducer over fail-nth=1..256yields no KASAN reports.[ idryomov: rename err_out_device_del -> err_out_device ]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0INVLPGA should cause a #UD when EFER.SVME is not set. Add a check toproperly inject #UD when EFER.SVME=0.[sean: tag for stable@]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fix resource leaks on device setup failureMake sure to call controller cleanup() if spi_setup() fails whileregistering a device to avoid leaking any resources allocated bysetup().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:zram: do not forget to endio for partial discard requestsAs reported by Qu Wenruo and Avinesh Kumar, the following getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0takes literally forever to complete. zram doesn't support partialdiscards and just returns immediately w/o doing any discard work in suchcases. The problem is that we forget to endio on our way out, soblkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping toend_bio label, which does bio_endio().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnelsseg6_input_core() and rpl_input() call ip6_route_input() which sets aNOREF dst on the skb, then pass it to dst_cache_set_ip6() invokingdst_hold() unconditionally.On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task canrelease the underlying pcpu_rt between the lookup and the cachingthrough a concurrent FIB lookup on a shared nexthop.Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-freeFor the race to occur, ksoftirqd must be preemptible (PREEMPT_RT withoutPREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to releasethe pcpu_rt. Shared nexthop objects provide such a path, as two routespointing to the same nhid share the same fib6_nh and its rt6i_pcpuentry.Fix seg6_input_core() and rpl_input() by calling skb_dst_force() afterip6_route_input() to force the NOREF dst into a refcounted one beforecaching.The output path is not affected as ip6_route_output() already returns arefcounted dst.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: strparser: fix skb_head leak in strp_abort_strp()When the stream parser is aborted, for example after a message assembly timeout,it can still hold a reference to a partially assembled message instrp->skb_head.That skb is not released in strp_abort_strp(), which leaks the partiallyassembled message and can be triggered repeatedly to exhaust memory.Fix this by freeing strp->skb_head and resetting the parser state in theabort path. Leave strp_stop() unchanged so final cleanup still happens instrp_done() after the work and timer have been synchronized.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: use sk blob accessor in socket permission helpersSELinux socket state lives in the composite LSM socket blob.sock_has_perm() and nlmsg_sock_has_extended_perms() currentlydereference sk->sk_security directly, which assumes the SELinux socketblob is at offset zero.In stacked configurations that assumption does not hold. If another LSMallocates socket blob storage before SELinux, these helpers may read thewrong blob and feed invalid SID and class values into AVC checks.Use selinux_sock() instead of accessing sk->sk_security directly.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: add pgmap check to biovec_phys_mergeablebiovec_phys_mergeable() is used by the request merge, DMA mapping,and integrity merge paths to decide if two physically contiguousbvec segments can be coalesced into one. It currently has no checkfor whether the segments belong to different dev_pagemaps.When zone device memory is registered in multiple chunks, each chunkgets its own dev_pagemap. A single bio can legitimately containbvecs from different pgmaps -- iov_iter_extract_bvecs() breaks atpgmap boundaries but the outer loop in bio_iov_iter_get_pages()continues filling the same bio. If such bvecs are physicallycontiguous, biovec_phys_mergeable() will coalesce them, making itimpossible to recover the correct pgmap for the merged segmentvia page_pgmap().Add a zone_device_pages_have_same_pgmap() check to prevent mergingbvec segments that span different pgmaps.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isofs: validate block number from NFS file handle in isofs_export_igetisofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker-controlled block number (ifid->block or ifid->parent_block) fromthe NFS file handle to isofs_export_iget(), which only rejectsblock == 0 before calling isofs_iget() and ultimately sb_bread().A crafted file handle with fh_len sufficient to pass the checkadded by commit 0405d4b63d08 ("isofs: Prevent the use of too smallfid") can still drive the server to read any in-range block on thebacking device as if it were an iso_directory_record. That earlierfix was assigned CVE-2025-37780.sb_bread() on an out-of-range block returns NULL cleanly via theEIO path, so there is no memory-safety violation. For in-rangereads of adjacent-partition data on the same block device, theunrelated bytes end up in iso_inode_info fields that reach the NFSclient as dentry metadata. The deployment surface (isofs exportedover NFS from loop-mounted images) is narrow and requires anauthenticated NFS peer, but the malformed-file-handle class isreportable as hardening next to the existing CVE-2025-37780 fix.Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() sothe check covers both isofs_fh_to_dentry() and isofs_fh_to_parent()call sites with a single line.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()Sashiko points out that pd->uctx isn't initialized until late in thefunction so all these error flow references are NULL and will crash. Usethe uctx that isn't NULL.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity-fec: fix reading parity bytes split across blocks (take 3)fec_decode_bufs() assumes that the parity bytes of the first RS codewordit decodes are never split across parity blocks.This assumption is false. Consider v->fec->block_size == 4096 &&v->fec->roots == 17 && fio->nbufs == 1, for example. In that case, eachcall to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs <
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfortnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stackwithout initialisation: struct ifla_vf_broadcast vf_broadcast;The struct contains a single fixed 32-byte field: /* include/uapi/linux/if_link.h */ struct ifla_vf_broadcast { __u8 broadcast[32]; };The function then copies dev->broadcast into it using dev->addr_lenas the length: memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);On Ethernet devices (the overwhelming majority of SR-IOV NICs)dev->addr_len is 6, so only the first 6 bytes of broadcast[] arewritten. The remaining 26 bytes retain whatever was previously onthe kernel stack. The full struct is then handed to userspace via: nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast), &vf_broadcast)leaking up to 26 bytes of uninitialised kernel stack per VF perRTM_GETLINK request, repeatable.The other vf_* structs in the same function are explicitly zeroedfor exactly this reason - see the memset() calls for ivi,vf_vlan_info, node_guid and port_guid a few lines above.vf_broadcast was simply missed when it was added.Reachability: any unprivileged local process can open AF_NETLINK /NETLINK_ROUTE without capabilities and send RTM_GETLINK with anIFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walkseach VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack perVF per request. Stack residue at this call site can include returnaddresses and transient sensitive data; KASAN with stackinstrumentation, or KMSAN, will flag the nla_put() when reproduced.Zero the on-stack struct before the partial memcpy, matching theexisting pattern used for the other vf_* structs in the samefunction.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Reject unknown opcodes before ICRC processingEven after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRCbefore payload_size() in rxe_rcv"), a single unauthenticated UDP packetcan still trigger panic. That patch handled payload_size() underflow onlyfor valid opcodes with short packets, not for packets carrying an unknownopcode. The unknown-opcode OOB read described below predates that commitand reaches back to the initial Soft RoCE driver.The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZEwhere header_size(pkt) expands to rxe_opcode[pkt->opcode].length. Therxe_opcode[] array has 256 entries but is only populated for defined IBopcodes; any other entry (for example opcode 0xff) is zero-initialized, solength == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZEwhich does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTESwhich underflows when length == 0 and passes a huge value to rxe_crc32(),causing an out-of-bounds read of the skb payload.Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM withCONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0A single 48-byte UDP packet to port 4791 with BTH opcode=0xff andQPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0Subsequent packets with the same shape fault on unmapped memory and panicthe kernel. The trigger requires only module load and "rdma link add"; noQP, no connection, and no authentication.Fix this by rejecting packets whose opcode has no rxe_opcode[] entry,detected via the zero mask or zero length, before any length arithmeticruns.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: microchip-core-qspi: control built-in cs manuallyThe coreQSPI IP supports only a single chip select, which isautomagically operated by the hardware - set low when the transmitbuffer first gets written to and set high when the number of byteswritten to the TOTALBYTES field of the FRAMES register have been sent onthe bus. Additional devices must use GPIOs for their chip selects.It was reported to me that if there are two devices attached to thisQSPI controller that the in-built chip select is set low while linuxtries to access the device attached to the GPIO.This went undetected as the boards that connected multiple devices tothe SPI controller all exclusively used GPIOs for chip selects, notrelying on the built-in chip select at all. It turns out that this wasbecause the built-in chip select, when controlled automagically, is setlow when active and high when inactive, thereby ruling out its use foractive-high devices or devices that need to transmit with the chipselect disabled.Modify the driver so that it controls chip select directly, retainingthe behaviour for mem_ops of setting the chip select active for theentire duration of the transfer in the exec_op callback. For regulartransfers, implement the set_cs callback for the core to use.As part of this, the existing setup callback, mchp_coreqspi_setup_op(),is removed. Modifying the CLKIDLE field is not safe to do duringoperation when there are multiple devices, so this code is removedentirely. Setting the MASTER and ENABLE fields is something that can bedone once at probe, it doesn't need to be re-run for each device.Instead the new setup callback sets the built-in chip select to itsinactive state for active-low devices, as the reset value of the chipselect in software controlled mode is low.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a256-byte stack buffer, then will memcpy() cur_len bytes from thatbuffer. snprintf() returns the length the output would have had, whichcan exceed the buffer size when the fabric WWN is long because iSCSI IQNnames can be up to 223 bytes. The check at the memcpy() site onlyguards the destination page write, not the source read, so memcpy() willread past the stack buffer and copy adjacent stack contents to the sysfsreader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic()will be triggered.Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add lengthcheck to avoid buffer overflow") added the same bound to thetarget_lu_gp_members_show() but the tg_pt_gp variant was missed soresolve that here.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: ADD_ADDR rtx: always decrease sk refcountWhen an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer().It should then be released in all cases at the end.Some (unlikely) checks were returning directly instead of callingsock_put() to decrease the refcount. Jump to a new 'exit' label to call__sock_put() (which will become sock_put() in the next commit) to fixthis potential leak.While at it, drop the '!msk' check which cannot happen because it isnever reset, and explicitly mark the remaining one as "unlikely".
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leakbtrfs_ioctl_space_info() has a TOCTOU race between two passes over theblock group RAID type lists. The first pass counts entries to determinethe allocation size, then the second pass fills the buffer. Thegroups_sem rwlock is released between passes, allowing concurrent blockgroup removal to reduce the entry count.When the second pass fills fewer entries than the first pass counted,copy_to_user() copies the full alloc_size bytes including trailinguninitialized kmalloc bytes to userspace.Fix by copying only total_spaces entries (the actually-filled count fromthe second pass) instead of alloc_size bytes, and switch to kzalloc soany future copy size mismatch cannot leak heap data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix missing last_unlink_trans update when removing a directoryWhen removing a directory we are not updating its last_unlink_trans field,which can result in incorrect fsync behaviour in case some one fsyncs thedirectory after it was removed because it's holding a file descriptor onit.Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path "/mnt/dir1" fsync fd When attempting to mount the filesystem, the log replay will fail withan -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] inode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] rdev 0 sequence 2 flags 0x0 [445771.638102] atime 1775744884.0 [445771.660056] ctime 1775744885.645502983 [445771.660058] mtime 1775744885.645502983 [445771.660060] otime 1775744884.0 [445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] index 0 name_len 2 [445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] location key (259 1 0) type 2 [445771.660070] transid 9 data_len 0 name_len 4 [445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] location key (257 1 0) type 2 [445771.660077] transid 9 data_len 0 name_len 4 [445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] location key (257 1 0) type 2 [445771.660080] transid 9 data_len 0 name_len 4 [445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] location key (259 1 0) type 2 [445771.660083] transid 9 data_len 0 name_len 4 [445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] inode generation 9 transid 9 size 8 nbytes 0 [445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] rdev 0 sequence 2 flags 0x0 [445771.660089] atime 1775744885.641174097 [445771.660090] ctime 1775744885.645502983 [445771.660091] mtime 1775744885.645502983 [445771.660105] otime 1775744885.641174097 [445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] index 2 name_len 4 [445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] location key (2---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix divide-by-zero in setup_geo() with zero far_copiessetup_geo() extracts near_copies (nc) and far_copies (fc) from theuser-provided layout parameter without checking for zero. When fc=0with the "improved" far set layout selected, 'geo->far_set_size =disks / fc' triggers a divide-by-zero.Validate nc and fc immediately after extraction, returning -1 ifeither is zero.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix double free in ice_sf_eth_activate() error pathWhen auxiliary_device_add() fails, ice_sf_eth_activate() jumps toaux_dev_uninit and calls auxiliary_device_uninit(&sf_dev->adev).The device release callback ice_sf_dev_release() frees sf_dev, butthe current error path falls through to sf_dev_free and callskfree(sf_dev) again, causing a double free.Keep kfree(sf_dev) for the auxiliary_device_init() failure path, butavoid falling through to sf_dev_free after auxiliary_device_uninit().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix scheduling with atomic in timestamp sockoptUsing lock_sock_fast() (atomic context) around sock_set_timestamp()and sock_set_timestamping() is unsafe, as both helpers can sleep.Replace lock_sock_fast() with sleepable lock_sock()/release_sock()to avoid scheduling while atomic panic.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does notalready have a dst attached. ip6_route_input_lookup() returns areferenced dst entry even when the lookup resolves to an error route.If dst->error is set, xfrm6_rcv_encap() drops the skb without attachingthe dst to the skb and without releasing the reference returned by thelookup. Repeated packets hitting this path therefore leak dst entries.Release the dst before jumping to the drop path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix fsck inconsistency caused by FGGC of node blockDuring FGGC node block migration, fsck may incorrectly treat themigrated node block as fsync-written data.The reproduction scenario:root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and syncroot@vm:/mnt/f2fs# rm -f 1root@vm:/mnt/f2fs# syncroot@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT setThe root cause is that GC does not clear the dentry mark and fsync markduring node block migration, leading fsck to misinterpret them asuser-issued fsync writes.In BGGC mode, node block migration is handled by f2fs_sync_node_pages(),which guarantees the dentry and fsync marks are cleared before writing.This patch move the set/clear of the fsync|dentry marks into__write_node_folio to make the logic clearer, and ensures thefsync|dentry mark is cleared in FGGC.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init()mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. Whenib_create_srq() fails for s1, the error branch destroys s0 but fallsthrough and unconditionally assigns the freed s0 and the ERR_PTR s1 todevr->s0 and devr->s1.This leads to several problems: the lock-free fast path checks"if (devr->s1) return 0;" and treats the ERR_PTR as already initialised;users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR viato_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferencesthe ERR_PTR and double-frees s0 on teardown.Fix by adding the same `goto unlock` in the s1 failure path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()Sashiko points out that mlx4_srq_alloc() was not undone during errorunwind, add the missing call to mlx4_srq_free().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog taskWatchdog task might end between send_sig() and kthread_stop() calls, whatresults in the use-after-free issue. Fix this by increasing watchdog taskreference count before calling send_sig() and dropping it by switching tokthread_stop_put().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()Sashiko points out the radix_tree itself is RCU safe, but nothing everfrees the mlx4_srq struct with RCU, and it isn't even accessed within theRCU critical section. It also will crash if an event is delivered beforethe srq object is finished initializing.Use the spinlock since it isn't easy to make RCU work, userefcount_inc_not_zero() to protect against partially initialized objects,and order the refcount_set() to be after the srq is fully initialized.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: fix out-of-bounds read in symlink_data()Since smb2_check_message() returns success without length validation forthe symlink error response, in symlink_data() it is possible foriov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the bufferonly contains the base SMB2 header (64 bytes), accessingerr->ErrorContextCount (at offset 66) or err->ByteCount later insymlink_data() will cause an out-of-bounds read.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error pathSashiko points out that pvrdma_uar_free() is already called withinpvrdma_dealloc_ucontext(), so calling it before triggers a double free.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Avoid OOB font access if console rotation failsClear the font buffer if the reallocation during console rotation failsin fbcon_rotate_font(). The putcs implementations for the rotated bufferwill return early in this case. See [1] for an example.Currently, fbcon_rotate_font() keeps the old buffer, which is too smallfor the rotated font. Printing to the rotated console with a high-enoughcharacter code will overflow the font buffer.v2:- fix typos in commit message
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: validate dacloffset before building DACL pointersparse_sec_desc(), build_sec_desc(), and the chown path inid_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsdbefore proving a DACL header fits inside the returned securitydescriptor.On 32-bit builds a malicious server can return dacloffset nearU32_MAX, wrap the derived DACL pointer below end_of_acl, and then slippast the later pointer-based bounds checks. build_sec_desc() andid_mode_to_cifs_acl() can then dereference DACL fields from the wrappedpointer in the chmod/chown rewrite paths.Validate dacloffset numerically before building any DACL pointer andreuse the same helper at the three DACL entry points.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func()invokes the subsystem's ext->regfunc() before attempting to install thenew probe via func_add(). If func_add() then fails (for example, whenallocate_probes() cannot allocate a new probe array under memory pressureand returns -ENOMEM), the function returns the error without calling thematching ext->unregfunc(), leaving the side effects of regfunc() behindwith no installed probe to justify them.For syscall tracepoints this is particularly unpleasant: syscall_regfunc()bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.After a leaked failure, the refcount is stuck at a non-zero value with noconsumer, and every task continues paying the syscall trace entry/exitoverhead until reboot. Other subsystems providing regfunc()/unregfunc()pairs exhibit similarly scoped persistent state.Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in thefunc_add() error path, gated on the same condition used there so theunwind is symmetric with the registration.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: mpc52xx: fix controller deregistrationMake sure to deregister the controller before disabling and releasingunderlying resources like interrupts and gpios during driver unbind.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: stop tp_meter sessions during mesh teardownTP meter sessions remain linked on bat_priv->tp_list after the netlinkrequest has already finished. When the mesh interface is removed,batadv_mesh_free() currently tears down the mesh without first drainingthese sessions.A running sender thread or a late incoming tp_meter packet can then keepprocessing against a mesh instance which is already shutting down.Synchronize tp_meter with the mesh lifetime by stopping all activesessions from batadv_mesh_free() and waiting for sender threads to exitbefore teardown continues.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()When media GT is disabled via configfs, there is no allocation formedia_gt, which is kept as NULL. In such scenario,intel_hdcp_gsc_check_status() results in a kernel pagefault error due to>->uc.gsc being evaluated as an invalid memory address.Fix that by introducing a NULL check on media_gt and bailing out earlyif so.While at it, also drop the NULL check for gsc, since it can't be NULL ifmedia_gt is not NULL.v2: - Get address for gsc only after checking that gt is not NULL. (Shuicheng) - Drop the NULL check for gsc. (Shuicheng)v3: - Add "Fixes" and "Cc: " tags. (Matt)(cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl: fix controller deregistrationMake sure to deregister the controller before releasing underlyingresources like DMA during driver unbind.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: fix buffer size clamping orderIn vsock_update_buffer_size(), the buffer size was being clamped to themaximum first, and then to the minimum. If a user sets a minimum buffersize larger than the maximum, the minimum check overrides the maximumcheck, inverting the constraint.This breaks the intended socket memory boundaries by allowing thevsk->buffer_size to grow beyond the configured vsk->buffer_max_size.Fix this by checking the minimum first, and then the maximum. Thisensures the buffer size never exceeds the buffer_max_size.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: mpc52xx: fix use-after-free on registration failureMake sure to disable and free the interrupts in case controllerregistration fails to avoid a potential use-after-free and resourceleak.This issue was flagged by Sashiko when reviewing a controllerderegistration fix.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: fix ep_remove struct eventpoll / struct file UAFep_remove() (via ep_remove_file()) cleared file->f_ep underfile->f_lock but then kept using @file inside the critical section(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).A concurrent __fput() taking the eventpoll_release() fastpath inthat window observed the transient NULL, skippedeventpoll_release_file() and ran to f_op->release / file_free().For the epoll-watches-epoll case, f_op->release isep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), whichkfree()s the watched struct eventpoll. Its embedded ->refshlist_head is exactly where epi->fllink.pprev points, so thesubsequent hlist_del_rcu()'s "*pprev = next" scribbles into freedkmalloc-192 memory.In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slotbacking @file could be recycled by alloc_empty_file() --reinitializing f_lock and f_ep -- while ep_remove() is stillnominally inside that lock. The upshot is an attacker-controllablekmem_cache_free() against the wrong slab cache.Pin @file via epi_fget() at the top of ep_remove() and gate thecritical section on the pin succeeding. With the pin held @filecannot reach refcount zero, which holds __fput() off andtransitively keeps the watched struct eventpoll alive across thehlist_del_rcu() and the f_lock use, closing both UAFs.If the pin fails @file has already reached refcount zero and its__fput() is in flight. Because we bailed before clearing f_ep,that path takes the eventpoll_release() slow path intoeventpoll_release_file() and blocks on ep->mtx until the waiterside's ep_clear_and_put() drops it. The bailed epi's share ofep->refcount stays intact, so the trailing ep_refcount_dec_and_test()in ep_clear_and_put() cannot free the eventpoll out from undereventpoll_release_file(); the orphaned epi is then cleaned upthere.A successful pin also proves we are not racingeventpoll_release_file() on this epi, so drop the now-redundantre-check of epi->dying under f_lock. The cheap locklessREAD_ONCE(epi->dying) fast-path bailout stays.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_inner: Fix IPv6 inner_thoff desyncIn nft_inner_parse_l2l3(), when processing inner IPv6 packets,ipv6_find_hdr() correctly computes the transport header offsettraversing all extension headers, but the result is immediatelyoverwritten with nhoff + sizeof(_ip6h) (40 bytes), which onlyaccounts for the IPv6 base header. This creates a desync betweeninner_thoff (wrong - points to extension header start) and l4proto(correct - e.g., IPPROTO_TCP), enabling transport header forgeryand potential firewall bypass. This issue affects stable versionsfrom Linux 6.2.For comparison, the normal (non-inner) IPv6 path correctlypreserves ipv6_find_hdr()'s result. Removing the incorrect overwriteensures that ipv6_find_hdr()'s calculated transport header offset ispreserved, thereby fixing the desynchronization.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix dc_link NULL handling in HPD initamdgpu_dm_hpd_init() may see connectors without a valid dc_link.The code already checks dc_link for the polling decision, but laterunconditionally dereferences it when setting up HPD interrupts.Assign dc_link early and skip connectors where it is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()error: we previously assumed 'dc_link' could be null (see line 931)drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c 923 /* 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 */ 927 use_polling |= 928 amdgpu_dm_connector->dc_link && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id); 930 931 dc_link = amdgpu_dm_connector->dc_link;dc_link assigned here. 932 933 /* 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on 937 * hpd_rx isn't available. DM currently controls hpd_rx 938 * explicitly with dc_interrupt_set() 939 */--> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1; 942 /* 943 * TODO: There's a mismatch between mode_info.num_hpd 944 * and what bios reports as the # of connectors with hpd
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Fix PF driver crash with kexec kernel bootingDuring a kexec reboot the hardware is not power-cycled, so AF state fromthe old kernel can persist into the new kernel. When AF and PF driversare built as modules, the PF driver may probe before AF reinitializesthe hardware.The PF driver treats the RVUM block revision as an indication that AFinitialization is complete. If this value is left uncleared at shutdown,PF may incorrectly assume AF is ready and access stale hardware state,leading to a crash.Clear the RVUM block revision during AF shutdown to avoid PFmis-detecting AF readiness after kexec.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix block_group_tree dirty_list corruptionWhen the incompat flag EXTENT_TREE_V2 is set, we unconditionally add theblock group tree to the switch_commits list before callingswitch_commit_roots, as we do for the tree root and the chunk root.However, the block group tree uses normal root dirty tracking and in anytransaction that does an allocation and dirties a block group, the blockgroup root will already be linked to a list by the dirty_list field andthis use of list_add_tail() is invalid and corrupts the prev/nextmembers of block_group_root->dirty_list.This is apparent on a subsequent list_del on the prev if we enableCONFIG_DEBUG_LIST: [32.1571] ------------[ cut here ]------------ [32.1572] list_del corruption. next->prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538) [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607 [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none) [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014 [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120 [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202 [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538 [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00 [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538 [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538 [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000 [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0 [32.1609] Call Trace: [32.1610] [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs] [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs] [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [32.1621] __iterate_supers+0xe8/0x190 [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10 [32.1623] ksys_sync+0x63/0xb0 [32.1624] __do_sys_sync+0xe/0x20 [32.1625] do_syscall_64+0x73/0x450 [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e [32.1627] RIP: 0033:0x7f0c28d05d2b [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2 [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000 [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80 [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034 [32.1643] [32.1644] irq event stamp: 0 [32.1644] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260 [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260 [32.1650] softirqs last disabled at (0): [<0000000000000000>] 0x0 [32.1652] ---[ end trace 0000000000000000 ]---Furthermore, this list corruption eventually (when we happen to add anew block group) results in getting the switch_commits anddirty_cowonly_roots lists mixed up and attempting to call update_rooton the tree root which can't be found in the tree root, resulting in atransaction abort: [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1 [87.8272] ------------[ cut here ]------------ [87.8274] BTRFS: Transaction aborted (error -117) [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703 [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none) [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 0---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pstore/ram: fix buffer overflow in persistent_ram_save_old()persistent_ram_save_old() can be called multiple times for the samepersistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_przfor PSTORE_TYPE_DMESG records).Currently, the function only allocates prz->old_log when it is NULL,but it unconditionally updates prz->old_log_size to the current buffersize and then performs memcpy_fromio() using this new size. If thebuffer size has grown since the first allocation (which can happenacross different kernel boot cycles), this leads to:1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_sizeThe KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ...The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() -> schedule_work() -> pstore_dowork() -> pstore_get_records(1) 9. ramoops_get_next_prz() -> persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives)Free and reallocate the buffer when the new size differs from thepreviously allocated size. This ensures old_log always has sufficientspace for the data being copied.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:AppArmor: Allow apparmor to handle unaligned dfa tablesThe dfa tables can originate from kernel or userspace and 8-byte alignmentisn't always guaranteed and as such may trigger unaligned memory accesseson various architectures. Resulting in the following[ 73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720[ 74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdromsd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common[ 74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE[ 74.536543] Call Trace:[ 74.568561] [<0000000000434c24>] dump_stack+0x8/0x18[ 74.633757] [<0000000000476438>] __warn+0xd8/0x100[ 74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74[ 74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720[ 74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0[ 74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300[ 74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0[ 75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160[ 75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280[ 75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100[ 75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420[ 75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0[ 75.406932] [<0000000000767174>] sys_write+0x14/0x40[ 75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44[ 75.548802] ---[ end trace 0000000000000000 ]---[ 75.609503] dfa blob stream 0xfff0000008926b96 not aligned.[ 75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720Work around it by using the get_unaligned_xx() helpers.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:procfs: fix missing RCU protection when reading real_parent in do_task_stat()When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parentwithout proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlockThis patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to addproper RCU protection for accessing task->real_parent.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix WQ_MEM_RECLAIM warningWhen sunrpc is used, if a reset triggered, our wq may lead thefollowing trace:workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma]is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle[hns_roce_hw_v2]WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144Call trace: check_flush_dependency+0xe0/0x144 start_flush_work.constprop.0+0x1d0/0x2f0 __flush_work.isra.0+0x40/0xb0 flush_work+0x14/0x30 hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2] ib_destroy_qp_user+0x9c/0x2b4 rdma_destroy_qp+0x34/0xb0 rpcrdma_ep_destroy+0x28/0xcc [rpcrdma] rpcrdma_ep_put+0x74/0xb4 [rpcrdma] rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma] xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib: test_hmm: evict device pages on file close to avoid use-after-freePatch series "Minor hmm_test fixes and cleanups".Two bugfixes a cleanup for the HMM kernel selftests. These were mostlyreported by Zenghui Yu with special thanks to Lorenzo for analysing andpointing out the problems.This patch (of 3):When dmirror_fops_release() is called it frees the dmirror struct butdoesn't migrate device private pages back to system memory first. Thisleaves those pages with a dangling zone_device_data pointer to the freeddmirror.If a subsequent fault occurs on those pages (eg. during coredump) thedmirror_devmem_fault() callback dereferences the stale pointer causing akernel panic. This was reported [1] when running mm/ksft_hmm.sh on arm64,where a test failure triggered SIGABRT and the resulting coredump walkedthe VMAs faulting in the stale device private pages.Fix this by calling dmirror_device_evict_chunk() for each devmem chunk indmirror_fops_release() to migrate all device private pages back to systemmemory before freeing the dmirror struct. The function is moved earlierin the file to avoid a forward declaration.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/scatterlist: fix length calculations in extract_kvec_to_sgPatch series "Fix bugs in extract_iter_to_sg()", v3.Fix bugs in the kvec and user variants of extract_iter_to_sg. This seriesis growing due to useful remarks made by sashiko.dev.The main bugs are:- The length for an sglist entry when extracting from a kvec can exceed the number of bytes in the page. This is obviously not intended.- When extracting a user buffer the sglist is temporarily used as a scratch buffer for extracted page pointers. If the sglist already contains some elements this scratch buffer could overlap with existing entries in the sglist.The series adds test cases to the kunit_iov_iter test that demonstrate allof these bugs. Additionally, there is a memory leak fix for the testitself.The bugs were orignally introduced into kernel v6.3 where the functionlived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c inv6.5. Thus the actual fix is only marked for backports to v6.5+.This patch (of 5):When extracting from a kvec to a scatterlist, do not cross pageboundaries. The required length was already calculated but not used asintended.Adjust the copied length if the loop runs out of sglist entries withoutextracting everything.While there, return immediately from extract_iter_to_sg if there are nosglist entries at all.A subsequent commit will add kunit test cases that demonstrate that thepatch is necessary.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - guard HMAC key hex dumps in hash_digest_keyUse print_hex_dump_devel() for dumping sensitive HMAC key bytes inhash_digest_key() to avoid leaking secrets at runtime whenCONFIG_DYNAMIC_DEBUG is enabled.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: core: Fix detach procedure for virtual devices in genpdIf a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),genpd calls pm_runtime_enable() for the corresponding virtual device thatit registers. While this avoids boilerplate code in drivers, there is nocorresponding call to pm_runtime_disable() in genpd_dev_pm_detach().This means these virtual devices are typically detached from its genpd,while runtime PM remains enabled for them, which is not how things aredesigned to work. In worst cases it may lead to critical errors, like aNULL pointer dereference bug in genpd_runtime_suspend(), which was recentlyreported. For another case, we may end up keeping an unnecessary vote for aperformance state for the device.To fix these problems, let's add this missing call to pm_runtime_disable()in genpd_dev_pm_detach().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: microchip: mpfs-ccc: fix out of bounds access during output registrationUBSAN reported an out of bounds access during registration of the lasttwo outputs. This out of bounds access occurs because space is onlyallocated in the hws array for two PLLs and the four output dividersthat each has, but the defined IDs contain two DLLS and their twooutputs each, which are not supported by the driver. The ID order isPLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDsby two while adding them to the array to avoid the problem.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix held lock freed on hfsplus_fill_super()hfsplus_fill_super() calls hfs_find_init() to initialize a searchstructure, which acquires tree->tree_lock. If the subsequent call tohfsplus_cat_build_key() fails, the function jumps to the out_put_rooterror label without releasing the lock. The later cleanup path thenfrees the tree data structure with the lock still held, triggering aheld lock freed warning.Fix this by adding the missing hfs_find_exit(&fd) call before jumpingto the out_put_root error label. This ensures that tree->tree_lock isproperly released on the error path.The bug was originally detected on v6.13-rc1 using an experimentalstatic analysis tool we are developing, and we have verified that theissue persists in the latest mainline kernel. The tool is specificallydesigned to detect memory management issues. It is currently under activedevelopment and not yet publicly available.We confirmed the bug by runtime testing under QEMU with x86_64 defconfig,lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, weused GDB to dynamically shrink the max_unistr_len parameter to 1 beforehfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturallyreturn -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() andexercises the faulty error path. The following warning was observedduring mount: ========================= WARNING: held lock freed! 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted ------------------------- mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 2 locks held by mount/174: #0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 #1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 stack backtrace: CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x82/0xd0 debug_check_no_locks_freed+0x13a/0x180 kfree+0x16b/0x510 ? hfsplus_fill_super+0xcb4/0x18a0 hfsplus_fill_super+0xcb4/0x18a0 ? __pfx_hfsplus_fill_super+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x65f/0xc30 ? srso_return_thunk+0x5/0x5f ? pointer+0x4ce/0xbf0 ? trace_contention_end+0x11c/0x150 ? __pfx_pointer+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x79b/0xc30 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? vsnprintf+0x6da/0x1270 ? srso_return_thunk+0x5/0x5f ? __mutex_unlock_slowpath+0x157/0x740 ? __pfx_vsnprintf+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? mark_held_locks+0x49/0x80 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? irqentry_exit+0x17b/0x5e0 ? trace_irq_disable.constprop.0+0x116/0x150 ? __pfx_hfsplus_fill_super+0x10/0x10 ? __pfx_hfsplus_fill_super+0x10/0x10 get_tree_bdev_flags+0x302/0x580 ? __pfx_get_tree_bdev_flags+0x10/0x10 ? vfs_parse_fs_qstr+0x129/0x1a0 ? __pfx_vfs_parse_fs_qstr+0x3/0x10 vfs_get_tree+0x89/0x320 fc_mount+0x10/0x1d0 path_mount+0x5c5/0x21c0 ? __pfx_path_mount+0x10/0x10 ? trace_irq_enable.constprop.0+0x116/0x150 ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x307/0x540 ? user_path_at+0x51/0x60 ? __x64_sys_mount+0x212/0x280 ? srso_return_thunk+0x5/0x5f __x64_sys_mount+0x212/0x280 ? __pfx___x64_sys_mount+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f do_syscall_64+0x111/0x680 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ffacad55eae Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 RSP: 002b---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: allow multiple opens of /sys/fs/selinux/policyCurrently there can only be a single open of /sys/fs/selinux/policy atany time. This allows any process to block any other process fromreading the kernel policy. The original motivation seems to have beena mix of preventing an inconsistent view of the policy size andpreventing userspace from allocating kernel memory without bound, butthis is arguably equally bad. Eliminate the policy_opened flag andshrink the critical section that the policy mutex is held. While weare making changes here, drop a couple of extraneous BUG_ONs.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:flow_dissector: do not dissect PPPoE PFC framesRFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOTRECOMMENDED for PPPoE. In practice, pppd does not support negotiatingPFC for PPPoE sessions, and the flow dissector driver has assumed anuncompressed frame until the blamed commit.During the review process of that commit [1], support for PFC issuggested. However, having a compressed (1-byte) protocol field meansthe subsequent PPP payload is shifted by one byte, causing 4-bytemisalignment for the network header and an unaligned access exceptionon some architectures.The exception can be reproduced by sending a PPPoE PFC frame to anethernet interface of a MIPS board, with RPS enabled, even if no PPPoEsession is active on that interface:$ 0 : 00000000 80c40000 00000000 85144817$ 4 : 00000008 00000100 80a75758 81dc9bb8$ 8 : 00000010 8087ae2c 0000003d 00000000$12 : 000000e0 00000039 00000000 00000000$16 : 85043240 80a75758 81dc9bb8 00006488$20 : 0000002f 00000007 85144810 80a70000$24 : 81d1bda0 00000000$28 : 81dc8000 81dc9aa8 00000000 805ead08Hi : 00009d51Lo : 2163358aepc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50ra : 805ead08 __skb_get_hash_net+0x74/0x12cStatus: 11000403 KERNEL EXL IECause : 40800010 (ExcCode 04)BadVA : 85144817PrId : 0001992f (MIPS 1004Kc)Call Trace:[<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50[<805ead08>] __skb_get_hash_net+0x74/0x12c[<805ef330>] get_rps_cpu+0x1b8/0x3fc[<805fca70>] netif_receive_skb_list_internal+0x324/0x364[<805fd120>] napi_complete_done+0x68/0x2a4[<8058de5c>] mtk_napi_rx+0x228/0xfec[<805fd398>] __napi_poll+0x3c/0x1c4[<805fd754>] napi_threaded_poll_loop+0x234/0x29c[<805fd848>] napi_threaded_poll+0x8c/0xb0[<80053544>] kthread+0x104/0x12c[<80002bd8>] ret_from_kernel_thread+0x14/0x1cCode: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000To reduce the attack surface and maintain performance, do not processPPPoE PFC frames.[1] https://lore.kernel.org/r/20220630231016.GA392@debian.home
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Reject empty multisync extension to prevent infinite loopv3d_get_extensions() walks a userspace-provided singly-linked list ofioctl extensions without any bound on the chain length. A local usercan craft a self-referential extension (ext->next == &ext) with zeroin_sync_count and out_sync_count, which bypasses the existing duplicate-extension guard: if (se->in_sync_count || se->out_sync_count) return -EINVAL;The guard never fires because v3d_get_multisync_post_deps() returnsimmediately when count is zero, leaving both fields at zero on everyiteration. The result is an infinite loop in kernel context, blockingthe calling thread and pegging a CPU core indefinitely.Fix this by rejecting a multisync extension where both in_sync_countand out_sync_count are zero in v3d_get_multisync_submit_deps(). Anempty multisync carries no synchronization information and serves nouseful purpose, so returning -EINVAL for such an extension is thecorrect defense against this attack vector.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/waitid: clear waitid info before copying it to userspaceIORING_OP_WAITID stores its result fields in struct io_waitid::info andlater copies them to userspace siginfo. The prep path initializes therequest arguments, but it does not initialize info itself.If the wait operation completes without reporting a child event, the commonwait code can return without writing wo_info. In that case io_waitid_finish()still copies iw->info to userspace, exposing stale bytes from the reusedio_kiocb command storage.Clear the result storage during prep so the io_uring path matches theregular waitid syscall, which uses a zero-initialized struct waitid_info.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: free page on short-frame rejection in tun_xdp_one()tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN withoutfreeing the page that vhost_net_build_xdp() allocated for it.tun_sendmsg() discards that -EINVAL and still returns total_len, sovhost_tx_batch() takes the success path and never frees the page; eachshort frame in a batch leaks one page-frag chunk.A local process that can open /dev/net/tun and /dev/vhost-net can hitthis path: it attaches a tun/tap device as the vhost-net backend andfeeds TX descriptors whose length minus the virtio-net header is belowETH_HLEN. Each kick leaks the page-frag chunks for that batch, and atight submission loop exhausts host memory and triggers an OOM panic.Free the page before returning -EINVAL, matching the XDP-program errorpath in the same function.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA: During rereg_mr ensure that REREG_ACCESS is compatibleIf IB_MR_REREG_ACCESS changes from RO to RW then the umem has to bere-evaluated to ensure it is properly pinned as RW. Since the umem ishidden inside each driver's mr struct add a ib_umem_check_rereg() functionthat each driver has to call before processing IB_MR_REREG_ACCESS.mlx4 has to retain its duplicate ib_access_writable check because itimplements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both itemsin place sequentially while the MR is live, so it will continue to notsupport this combination.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: v: stop OGMv2 on disabled interfaceWhen a batadv_hard_iface is disabled, its mesh_iface pointer is set toNULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs viabatadv_v_ogm_queue_on_if() for interfaces that have since lost theirmesh_iface association. This results in a NULL pointer dereference whenbatadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on thenow NULL hard_iface->mesh_iface to retrieve the batadv_priv.It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks thatit is using the same mesh_iface for which batadv_v_ogm_send_meshif() wascalled.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: stop hash:* range iteration at endThe following hash set variants:hash:ip,markhash:ip,porthash:ip,port,iphash:ip,port,netiterate IPv4 ranges with a 32-bit iterator.The iterator must stop once the last address in the requested range hasbeen processed. Advancing it once more can move the traversal state pastthe end of the request, so a later retry may continue from an unintendedposition.Handle the iterator increment explicitly at the end of the loop and stoponce the upper bound has been processed. This keeps the existing retrybehaviour intact for valid ranges while preventing traversal fromcontinuing past the original boundary.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vrf: Fix a potential NPD when removing a port from a VRFRCU readers that identified a net device as a VRF port usingnetif_is_l3_slave() assume that a subsequent call tonetdev_master_upper_dev_get_rcu() will return a VRF device. They thencontinue to dereference its l3mdev operations.This assumption is not always correct and can result in a NPD [1]. Thereis no RCU synchronization when removing a port from a VRF, so it ispossible for an RCU reader to see a new master device (e.g., a bridge)that does not have l3mdev operations.Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVEflag. Skip this synchronization when a net device is removed from a VRFas part of its deletion and when the VRF device itself is deleted. Inthe latter case an RCU grace period will pass by the time RTNL isreleased.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181)[...]Call Trace:l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189)__inet_bind (net/ipv4/af_inet.c:499 (discriminator 3))inet_bind_sk (net/ipv4/af_inet.c:469)__sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1))__x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1))do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: clear current gateway during teardownbatadv_gw_node_free() removes the gateway list entries during mesh teardown,but it does not clear the currently selected gateway. This leaves stalegateway state behind across cleanup and can break a later mesh recreation.Clear bat_priv->gw.curr_gw before walking the gateway list so the selectedgateway reference is dropped as part of teardown.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Reject SIOCATMARK on non-stream socketsSIOCATMARK reports whether the receive queue is at the urgent mark forMSG_OOB.In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets.SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(),so they should not support SIOCATMARK either.Return -EOPNOTSUPP for non-stream sockets before checking the receivequeue.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: stream: fully roll back denied add-stream stateWhen ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks andthen lowers outcnt. That leaves removed stream metadata behind, so alater re-add can reuse a stale ext and hit a null-pointer dereference inthe scheduler get path.Fix the rollback by tearing down the removed stream state the same wayother stream resizes do. Unschedule the current scheduler state, dropthe removed stream ext state with sctp_stream_outq_migrate(), and thenreschedule the remaining streams.This keeps scheduler-private RR/FC/PRIO lists consistent while fullyrolling back denied outgoing stream additions.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipc/shm: serialize orphan cleanup with shm_nattch updatesshm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but thatdoes not serialize all fields tested by shm_may_destroy(). In particular,shm_nattch is updated while holding shm_perm.lock, and attach paths can dothat without holding the rwsem.Do not decide that an orphaned segment is unused before taking the objectlock. Move the shm_may_destroy() check under shm_perm.lock, matching theother destroy paths, and unlock the segment when it no longer qualifiesfor removal.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/poll: fix signed comparison in io_poll_get_ownership()io_poll_get_ownership() uses a signed comparison to check whetherpoll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS))atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG(BIT(31)) is set in poll_refs, the value becomes negative insigned arithmetic, so the >= 128 comparison always evaluates tofalse and the slowpath is never taken.Fix this by casting the atomic_read() result to unsigned intbefore the comparison, so that the cancel flag is treated as alarge positive value and correctly triggers the slowpath.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: tvlv: reject oversized TVLV packetsbatadv_tvlv_container_ogm_append() builds a TVLV packet section fromthe tvlv.container_list. The total size of this section is computed bybatadv_tvlv_container_list_size(), which sums the sizes of all registeredcontainers.The return type and accumulator in batadv_tvlv_container_list_size() wereu16. If the accumulated size exceeds U16_MAX, the value wraps around,causing the subsequent allocation in batadv_tvlv_container_ogm_append()to be undersized. The memcpy-style copy that follows would then writebeyond the end of the allocated buffer, corrupting kernel memory.Fix this by widening the return type of batadv_tvlv_container_list_size()to size_t. In batadv_tvlv_container_ogm_append(), check the computed lengthagainst U16_MAX before proceeding, and bail out as if the allocation hadfailed when the limit is exceeded.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: espintcp: do not reuse an in-progress partial sendespintcp keeps a single in-flight transmit in ctx->partial.Before building a new sk_msg, espintcp_sendmsg() first tries to flushthat state through espintcp_push_msgs().For blocking callers, espintcp_push_msgs() may return success even whenthe previous partial send is still pending. espintcp_sendmsg() wouldthen reinitialize emsg->skmsg and reuse ctx->partial while the oldtransfer still owns that state.Do not rebuild the send message when ctx->partial is still in progress.If espintcp_push_msgs() returns with emsg->len still set, fail the newsend instead of overwriting the live partial state.This is a memory-safety fix: reusing the live partial-send state canleave a stale offset attached to a new sk_msg and lead to an out-of-bounds read in the send path.tcp_sendmsg_locked() already handles waiting for send buffer memory, sothe fix here is just to preserve espintcp's one-message-at-a-timetransmit state.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDRIn the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of anuninitialised on-stack struct sockaddr_storage to userspace viaifr_hwaddr, but netif_get_mac_address() only writes sa_family anddev->addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on amacvtap chardev returns kernel .text and direct-map pointers, defeatingKASLR.Initialise ss at declaration.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completionrds_ib_xmit_atomic() always programs a masked atomic opcode(IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD)for every RDS atomic cmsg. But the completion-side switch inrds_ib_send_unmap_op() only handles the non-masked opcodes, so a maskedatomic completion falls through to default and returns rm == NULL whilesend->s_op is left set. rds_ib_send_cqe_handler() then dereferences theNULL rm via rm->m_final_op, oopsing in softirq context. An unprivilegedAF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connectiontriggers it; on hardware that natively accepts masked atomics (mlx4,mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interruptHandle the masked atomic opcodes in the same case as the non-maskedones: they map to the same struct rds_message.atomic union member, sothe existing container_of()/rds_ib_send_unmap_atomic() body is correctfor them.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepointThe smc_msg_event tracepoint class, shared by smc_tx_sendmsg andsmc_rx_recvmsg, unconditionally dereferences smc->conn.lnk: __string(name, smc->conn.lnk->ibname)conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code onthese paths already handles this (e.g. !conn->lnk inSMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the firstsendmsg()/recvmsg() on an SMC-D socket crashes: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [...] RIP: 0010:strlen+0x1e/0xa0 Call Trace: trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44) smc_rx_recvmsg (net/smc/smc_rx.c:515) smc_recvmsg (net/smc/af_smc.c:2859) __sys_recvfrom (net/socket.c:2315) __x64_sys_recvfrom (net/socket.c:2326) do_syscall_64The faulting address 0x3e0 is offsetof(struct smc_link, ibname),confirming the NULL ->lnk deref. Enabling the tracepoint requiresroot, but the trigger itself is unprivileged: socket(AF_SMC, ...) hasno capability check, and SMC-D negotiation needs no admin step ons390 or on x86 with the loopback ISM device loaded.Log an empty device name for SMC-D instead of dereferencing NULL.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_log: validate MAC header was set before dumping itThe fallback path of dump_mac_header() guards the MAC header accessonly with "skb->mac_header != skb->network_header", without checkingskb_mac_header_was_set(). When the MAC header is unset, mac_header is0xffff, so the test passes and skb_mac_header(skb) returnsskb->head + 0xffff, ~64 KiB past the buffer; the loop then readsdev->hard_header_len bytes out of bounds into the kernel log.This is reachable via the netdev logger: nf_log_unknown_packet() callsdump_mac_header() unconditionally, and an skb sent through AF_PACKETwith PACKET_QDISC_BYPASS reaches the egress hook with mac_header stillunset (__dev_queue_xmit(), which would reset it, is bypassed).Add the skb_mac_header_was_set() check the ARPHRD_ETHER path alreadyuses, and replace the open-coded MAC header length test withskb_mac_header_len(). Only skbs with an unset MAC header are affected;valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: fix refcount saturation and potential UAF in qrtr_port_removeIn qrtr_port_remove(), the socket reference count is decremented via__sock_put() before the port is removed from the qrtr_ports XArray andbefore the RCU grace period elapses.This breaks the fundamental RCU update paradigm. It exposes a racewindow where a concurrent RCU reader (such as qrtr_reset_ports() orqrtr_port_lookup()) can obtain a pointer to the socket from the XArray,and attempt to call sock_hold() on a socket whose reference count hasalready dropped to zero.This exact race condition was hit during syzkaller fuzzing, leading tothe following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after thexa_erase() and the synchronize_rcu() complete.(Note: The v1 of this patch incorrectly replaced __sock_put() withsock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove()still hold a reference to the socket, so freeing the socket memory herewould lead to a subsequent UAF in the caller. Thus, the __sock_put() iskept, but only repositioned to close the RCU race.)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctlWhile fuzzing with Syzkaller, a persistent `schedule_timeout: wrongtimeout value` warning was observed, accompanied by SMBus controllerstate machine corruption.The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of10 ms. The user argument is checked against INT_MAX, but it issubsequently multiplied by 10 before being passed to msecs_to_jiffies().A malicious user can pass a large value (e.g., 429496729) that passesthe `arg > INT_MAX` check but overflows when multiplied by 10. Thisresults in a truncated 32-bit unsigned value that bypasses theinternal `(int)m < 0` check in `msecs_to_jiffies()`.The truncated value is then assigned to `client->adapter->timeout`(a signed 32-bit int), which is reinterpreted as a negative number.When passed to wait_for_completion_timeout(), this negative valueundergoes sign extension to a 64-bit unsigned long, triggering the`schedule_timeout` warning and causing premature returns. This leavesthe SMBus state machine in an unrecoverable state, constituting alocal Denial of Service (DoS).Fix this by bounding the user argument to `INT_MAX / 10`.[wsa: move the comment as well]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob sizeThe generic/642 test-case can reproduce the kernel crash:[40243.605254] ------------[ cut here ]------------[40243.605956] kernel BUG at fs/ceph/xattr.c:918![40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI[40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)[40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[40243.611820] Workqueue: ceph-msgr ceph_con_workfn[40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0[40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc[40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287[40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000[40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000[40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000[40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000[40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd[40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000[40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0[40243.627408] Call Trace:[40243.627839] [40243.628188] __prep_cap+0x3fd/0x4a0[40243.628789] ? do_raw_spin_unlock+0x4e/0xe0[40243.629474] ceph_check_caps+0x46a/0xc80[40243.630094] ? __lock_acquire+0x4a2/0x2650[40243.630773] ? find_held_lock+0x31/0x90[40243.631347] ? handle_cap_grant+0x79f/0x1060[40243.632068] ? lock_release+0xd9/0x300[40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340[40243.633429] ? lock_release+0xd9/0x300[40243.634052] handle_cap_grant+0xcf6/0x1060[40243.634745] ceph_handle_caps+0x122b/0x2110[40243.635415] mds_dispatch+0x5bd/0x2160[40243.636034] ? ceph_con_process_message+0x65/0x190[40243.636828] ? lock_release+0xd9/0x300[40243.637431] ceph_con_process_message+0x7a/0x190[40243.638184] ? kfree+0x311/0x4f0[40243.638749] ? kfree+0x311/0x4f0[40243.639268] process_message+0x16/0x1a0[40243.639915] ? sg_free_table+0x39/0x90[40243.640572] ceph_con_v2_try_read+0xf58/0x2120[40243.641255] ? lock_acquire+0xc8/0x300[40243.641863] ceph_con_workfn+0x151/0x820[40243.642493] process_one_work+0x22f/0x630[40243.643093] ? process_one_work+0x254/0x630[40243.643770] worker_thread+0x1e2/0x400[40243.644332] ? __pfx_worker_thread+0x10/0x10[40243.645020] kthread+0x109/0x140[40243.645560] ? __pfx_kthread+0x10/0x10[40243.646125] ret_from_fork+0x3f8/0x480[40243.646752] ? __pfx_kthread+0x10/0x10[40243.647316] ? __pfx_kthread+0x10/0x10[40243.647919] ret_from_fork_asm+0x1a/0x30[40243.648556] [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore[40243.654766] ---[ end trace 0000000000000000 ]---Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDSmaximum xattr size") moved the required_blob_size computation to beforethe __build_xattrs() call, introducing a race.__build_xattrs() releases and reacquires i_ceph_lock during execution.In that window, handle_cap_grant() may update i_xattrs.blob with anewer MDS-provided blob and bump i_xattrs.version. When__bui---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failureWhen ttm_tt_swapout() fails, the current code callsttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail()to restore the resource's bulk_move membership.However, ttm_resource_move_to_lru_tail() places the resource at the tailof the LRU list which, relative to the walk cursor's hitch node (placedimmediately after the resource when it was yielded), puts the resource*in front of the* the hitch. The next list_for_each_entry_continue() fromthe hitch finds the same resource again, causing an infinite loop.Fix by deferring del_bulk_move to the success path only.On the success path, TTM_TT_FLAG_SWAPPED has just been set byttm_tt_swapout() but the resource is still tracked in the bulk_move range,so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard wouldincorrectly skip the removal. Introducettm_resource_del_bulk_move_unevictable() which bypasses that guard.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: 3ad: implement proper RCU rules for port->aggregatorsyzbot found a data-race in bond_3ad_get_active_agg_info /bond_3ad_state_machine_handler [1] which hints at lack of properRCU implementation.Add __rcu qualifier to port->aggregator, and add proper RCU API.[1]BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handlerwrite to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0: ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline] bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569 process_one_work kernel/workqueue.c:3302 [inline] process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385 worker_thread+0x58a/0x780 kernel/workqueue.c:3466 kthread+0x22a/0x280 kernel/kthread.c:436 ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1: __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline] bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881 bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853 rtnl_link_info_fill net/core/rtnetlink.c:906 [inline] rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927 rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168 rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453 rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline] rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495 __dev_notify_flags+0x76/0x390 net/core/dev.c:9790 netif_change_flags+0xac/0xd0 net/core/dev.c:9823 do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180 rtnl_group_changelink net/core/rtnetlink.c:3813 [inline] __rtnl_newlink net/core/rtnetlink.c:3981 [inline] rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109 rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995 netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x563/0x5b0 net/socket.c:2698 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787 x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x0000000000000000 -> 0xffff88813cf5c400Reported by Kernel Concurrency Sanitizer on:CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full)Tainted: [W]=WARNHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: netem: fix queue limit check to include reordered packetsThe queue limit check in netem_enqueue() uses q->t_len which onlycounts packets in the internal tfifo. Packets placed in sch->q bythe reorder path (__qdisc_enqueue_head) are not counted, allowingthe total queue occupancy to exceed sch->limit under reordering.Include sch->q.qlen in the limit check.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: zero initialize struct iphdr in dummy sk_buffSyzbot reports a KMSAN uninit-value originating fromnsim_dev_trap_skb_build, with the allocation alsobeing performed in the same function.Fix this by calling skb_put_zero instead of skb_put toguarantee zero initialization of the whole IP header.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/psi: fix race between file release and pressure writeA potential race condition exists between pressure write and cgroup filerelease regarding the priv member of struct kernfs_open_file, whichtriggers the uaf reported in [1].Consider the following scenario involving execution on two separate CPUs: CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->privThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguardsthe memory deallocation of of->priv performed within cgroup_file_release().However, the operations involving of->priv executed within pressure_write()are not entirely covered by the protection of cgroup_mutex. Consequently,if the code in pressure_write(), specifically the section handling thectx variable executes after cgroup_file_release() has completed, a uafvulnerability involving of->priv is triggered.Therefore, the issue can be resolved by extending the scope of thecgroup_mutex lock within pressure_write() to encompass all code pathsinvolving of->priv, thereby properly synchronizing the race conditionoccurring between cgroup_file_release() and pressure_write().And, if an live kn lock can be successfully acquired while executingthe pressure write operation, it indicates that the cgroup deletionprocess has not yet reached its final stage; consequently, the privpointer within open_file cannot be NULL. Therefore, the operation toretrieve the ctx value must be moved to a point *after* the live knlock has been successfully acquired.In another situation, specifically after entering cgroup_kn_lock_live()but before acquiring cgroup_mutex, there exists a different class ofrace condition:CPU0: write memory.pressure CPU1: write cgroup.pressure=0=========================== =============================kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereferenceConsequently, there is a possibility that of->priv is NULL, the pressurewrite needs to check for this.Now that the scope of the cgroup_mutex has been expanded, the originalexplicit cgroup_get/put operations are no longer necessary, this isbecause acquiring/releasing the live kn lock inherently executes acgroup get/put operation.[1]BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/adfs: validate nzones in adfs_validate_bblk()Reject ADFS disc records with a zero zone count during boot blockvalidation, before the disc record is used.When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...)which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes todm[-1], causing an out-of-bounds write before the allocated buffer.adfs_validate_dr0() already rejects nzones != 1 for old-formatimages. Add the equivalent check to adfs_validate_bblk() fornew-format images so that a crafted image with nzones == 0 isrejected at probe time.Found by syzkaller.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix MSG_ZEROCOPY pinned-pages accountingvirtio_transport_init_zcopy_skb() uses iter->count as the size argumentfor msg_zerocopy_realloc(), which in turn passes it tomm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, thisfunction is called after virtio_transport_fill_skb() has already consumedthe iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->countwill be 0, skipping the RLIMIT_MEMLOCK enforcement.Pass pkt_len (the total bytes being sent) as an explicit parameter tovirtio_transport_init_zcopy_skb() instead of reading the already-consumediter->count.This matches TCP and UDP, which both call msg_zerocopy_realloc() withthe original message size.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: zero per-item info buffer before handing it to visitorsrds_for_each_conn_info() and rds_walk_conn_path_info() both hand acaller-allocated on-stack u64 buffer to a per-connection visitor andthen copy the full item_len bytes back to user space viards_info_copy() regardless of how much of the buffer the visitoractually wrote.rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() onlywrite a subset of their output struct when the underlyingrds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sland the two GIDs via explicit memsets). Several u32 fields(max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size,cache_allocs) and the 2-byte alignment hole between sl andcache_allocs remain as whatever stack contents preceded the visitorcall and are then memcpy_to_user()'d out to user space.struct rds_info_rdma_connection and struct rds6_info_rdma_connectionare the only rds_info_* structs in include/uapi/linux/rds.h that arenot marked __attribute__((packed)), so they have a real alignmenthole. The other info visitors (rds_conn_info_visitor,rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields oftheir packed output struct today and are not known to be vulnerable,but a future visitor that adds a conditional write-path would havethe same bug.Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y:a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB,binds to a local address on an RDMA-capable netdev (rxe soft-RoCE onany netdev is sufficient), sendto()'s any peer on the same subnet(fails cleanly but installs an rds_connection in the global hash inRDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS,RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage)Fix by zeroing the per-item buffer in both rds_for_each_conn_info()and rds_walk_conn_path_info() before invoking the visitor. Thiscovers the IPv4/IPv6 IB visitors and hardens all current and futurevisitors against the same class of bug.No functional change for visitors that fully populate their output.Changes in v2:- retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title)- pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_osf: fix potential NULL dereference in ttl checkThe nf_osf_ttl() function accessed skb->dev to perform a local interfaceaddress lookup without verifying that the device pointer was valid.Additionally, the implementation utilized an in_dev_for_each_ifa_rculoop to match the packet source address against local interfaceaddresses. It assumed that packets from the same subnet should not see adecrement on the initial TTL. A packet might appear it is from the samesubnet but it actually isn't especially in modern environments withcontainers and virtual switching.Remove the device dereference and interface loop. Replace the logic witha switch statement that evaluates the TTL according to the ttl_check.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_osf: fix out-of-bounds read on option matchingIn nf_osf_match(), the nf_osf_hdr_ctx structure is initialized onceand passed by reference to nf_osf_match_one() for each fingerprintchecked. During TCP option parsing, nf_osf_match_one() advances theshared ctx->optp pointer.If a fingerprint perfectly matches, the function returns early withoutrestoring ctx->optp to its initial state. If the user has configuredNF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint.However, because ctx->optp was not restored, the next call tonf_osf_match_one() starts parsing from the end of the options buffer.This causes subsequent matches to read garbage data and failimmediately, making it impossible to log more than one match or loggingincorrect matches.Instead of using a shared ctx->optp pointer, pass the context as aconstant pointer and use a local pointer (optp) for TCP optiontraversal. This makes nf_osf_match_one() strictly stateless from thecaller's perspective, ensuring every fingerprint check starts at thecorrect option offset.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nat: use kfree_rcu to release opsFlorian Westphal says:"Historically this is not an issue, even for normal base hooks: the datapath doesn't use the original nf_hook_ops that are used to register thecallbacks.However, in v5.14 I added the ability to dump the active netfilterhooks from userspace.This code will peek back into the nf_hook_ops that are availableat the tail of the pointer-array blob used by the datapath.The nat hooks are special, because they are called indirectly fromthe central nat dispatcher hook. They are currently invisible tothe nfnl hook dump subsystem though.But once that changes the nat ops structures have to be deferred too."Update nf_nat_register_fn() to deal with partial exposition of the hooksfrom error path which can be also an issue for nfnetlink_hook.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: restrict several matches to inet familyThis is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions")to allow ipv4 and ipv6 only.- xt_mac- xt_owner- xt_physdevThese extensions are not used by ebtables in userspace.Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4specific.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: remove sprintf usageReplace it with scnprintf, the buffer sizes are expected to be large enoughto hold the result, no need for snprintf+overflow check.Increase buffer size in mangle_content_len() while at it.BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pppoe: drop PFC framesRFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOTRECOMMENDED for PPPoE. In practice, pppd does not support negotiatingPFC for PPPoE sessions, and the current PPPoE driver assumes anuncompressed (2-byte) protocol field. However, the generic PPP layerfunction ppp_input() is not aware of the negotiation result, and stillaccepts PFC frames.If a peer with a broken implementation or an attacker sends a frame witha compressed (1-byte) protocol field, the subsequent PPP payload isshifted by one byte. This causes the network header to be 4-bytemisaligned, which may trigger unaligned access exceptions on somearchitectures.To reduce the attack surface, drop PPPoE PFC frames. Introduceppp_skb_is_compressed_proto() helper function to be used in bothppp_generic.c and pppoe.c to avoid open-coding.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunkssctp_getsockopt_peer_auth_chunks() checks that the caller's optvalbuffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL;but then writes num_chunks bytes to p->gauth_chunks, which livesat offset offsetof(struct sctp_authchunks, gauth_chunks) == 8inside optval. The check is missing the sizeof(structsctp_authchunks) = 8-byte header. When the caller supplieslen == num_chunks (for any num_chunks > 0) the test passes butcopy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytespast the declared buffer.The sibling function sctp_getsockopt_local_auth_chunks() at thenext line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL;Align the peer variant with its sibling.Reproducer confirms on v7.0-13-generic: an unprivileged userspacecaller that opens a loopback SCTP association with AUTH enabled,queries num_chunks with a short optval, then issues the realgetsockopt with len == num_chunks and sentinel bytes painted pastthe buffer observes those sentinel bytes overwritten with thepeer's AUTH chunk type. The bytes written are under the peer'scontrol but land in the caller's own userspace; this is not akernel memory corruption, but it is a kernel-side contractviolation that can silently corrupt adjacent userspace data.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Drop all SCM attributes for SOCKMAP.SOCKMAP can hide inflight fd from AF_UNIX GC.When a socket in SOCKMAP receives skb with inflight fd,sk_psock_verdict_data_ready() looks up the mapped socket andenqueue skb to its psock->ingress_skb.Since neither the old nor the new GC can inspect the psockqueue, the hidden skb leaks the inflight sockets. Note thatthis cannot be detected via kmemleak because inflight socketsare linked to a global list.In addition, SOCKMAP redirect breaks the Tarjan-based GC'sassumption that unix_edge.successor is always alive, whichis no longer true once skb is redirected, resulting inuse-after-free below. [0]Moreover, SOCKMAP does not call scm_stat_del() properly,so unix_show_fdinfo() could report an incorrect fd count.sk_msg_recvmsg() does not support any SCM attributes in thefirst place.Let's drop all SCM attributes before passing skb to theSOCKMAP layer.[0]:BUG: KASAN: slab-use-after-free in unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251)Read of size 8 at addr ffff888125362670 by task kworker/56:1/496CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014Workqueue: events sk_psock_backlogCall Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379) kasan_report (mm/kasan/report.c:597) unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) unix_destroy_fpl (net/unix/garbage.c:317) unix_destruct_scm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/af_unix.c:1976) sk_psock_backlog (./include/linux/skbuff.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Allocated by task 955: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) __kasan_slab_alloc (mm/kasan/common.c:369) kmem_cache_alloc_noprof (mm/slub.c:4539) sk_prot_alloc (net/core/sock.c:2240) sk_alloc (net/core/sock.c:2301) unix_create1 (net/unix/af_unix.c:1099) unix_create (net/unix/af_unix.c:1169) __sock_create (net/socket.c:1606) __sys_socketpair (net/socket.c:1811) __x64_sys_socketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860) do_syscall_64 (arch/x86/entry/syscall_64.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)Freed by task 496: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kmem_cache_free (mm/slub.c:6165) __sk_destruct (net/core/sock.c:2282 net/core/sock.c:2384) sk_psock_destroy (./include/net/sock.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible UAF in icmpv6_rcv()Caching saddr and daddr before pskb_pull() is problematicsince skb->head can change.Remove these temporary variables:- We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path.- Avoid potential future misuse after pskb_pull() call.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix double-free of tx_buf skbIf ice_tso() or ice_tx_csum() fail, the error path inice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still pointsto it and is marked as valid (ICE_TX_BUF_SKB).'next_to_use' remains unchanged, so the potential problem willlikely fix itself when the next packet is transmitted and the tx_bufgets overwritten. But if there is no next packet and the interface isbrought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf()will find the tx_buf and free the skb for the second time.The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the errorpath, so that ice_unmap_and_free_tx_buf().Move the initialization of 'first' up, to ensure it's already valid incase we hit the linearization error path.The bug was spotted by AI while I had it looking for something else.It also proposed an initial version of the patch.I reproduced the bug and tested the fix by adding code to injectfailures, on a build with KASAN.I looked for similar bugs in related Intel drivers and did not find any.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: fix use-after-free in advance_sched() on schedule switchIn advance_sched(), when should_change_schedules() returns true,switch_schedules() is called to promote the admin schedule to oper.switch_schedules() queues the old oper schedule for RCU freeing viacall_rcu(), but 'next' still points into an entry of the old operschedule. The subsequent 'next->end_time = end_time' andrcu_assign_pointer(q->current_entry, next) are use-after-free.Fix this by selecting 'next' from the new oper schedule immediatelyafter switch_schedules(), and using its pre-calculated end_time.setup_first_end_time() sets the first entry's end_time tobase_time + interval when the schedule is installed, so the valueis already correct.The deleted 'end_time = sched_base_time(admin)' assignment was alsoharmful independently: it would overwrite the new first entry'spre-calculated end_time with just base_time.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFFmacvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, butmacvlan_fill_info() conditionally includes it when port->bc_cutoff != 1.This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skbruns out of space, triggering a WARN_ON in rtnetlink and preventing theinterface from being dumped.The bug can be reproduced with: ip link add macvlan0 link eth0 type macvlan mode bridge ip link set macvlan0 type macvlan bc_cutoff 0 ip -d link show macvlan0 # fails with -EMSGSIZEThe bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Addnetlink attribute for broadcast cutoff"), which added the nla_put_s32()call in macvlan_fill_info() but missed adding the correspondingnla_total_size(4) in macvlan_get_size(). A follow-up commit55cef78c244d ("macvlan: add forgotten nla_policy forIFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but stilldid not fix the size calculation.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: unify lcn as u64 for 32-bit platformsAs sashiko reported [1], `lcn` was typed as `unsigned long` (or`unsigned int` sometimes), which is only 32 bits wide on 32-bitplatforms, which causes `(lcn << lclusterbits)` to be truncatedat 4 GiB.In order to consolidate the logic, just use `u64` consistentlyaround the codebase.[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix data loss caused by incorrect use of nat_entry flagData loss can occur when fsync is performed on a newly created file(before any checkpoint has been written) concurrently with a checkpointoperation. The scenario is as follows:create & write & fsync 'file A' write checkpoint- f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return false SPO and lost 'file A'f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNCflags for the nat_entry, but this does not mean that the checkpoint hasactually completed successfully. However, f2fs_need_inode_block_update()checks these flags and incorrectly assumes that the checkpoint hasfinished.The root cause is that the semantics of IS_CHECKPOINTED andHAS_LAST_FSYNC are only guaranteed after the checkpoint write fullycompletes.This patch modifies f2fs_need_inode_block_update() to acquire thesbi->node_write lock before reading the nat_entry flags, ensuring thatonce IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, thecheckpoint operation has already completed.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: avoid reading already updated pages during GCWe found the following issue during fuzz testing:page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9memcg:f8ffff800e269c00aops:f2fs_meta_aops ino:2flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a)raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00page dumped because: VM_BUG_ON_FOLIO(folio_test_uptodate(folio))page_owner tracks the page as allocated post_alloc_hook+0x58c/0x5ec prep_new_page+0x34/0x284 get_page_from_freelist+0x2dcc/0x2e8c __alloc_pages_noprof+0x280/0x76c __folio_alloc_noprof+0x18/0xac __filemap_get_folio+0x6bc/0xdc4 pagecache_get_page+0x3c/0x104 do_garbage_collect+0x5c78/0x77a4 f2fs_gc+0xd74/0x25f0 gc_thread_func+0xb28/0x2930 kthread+0x464/0x5d8 ret_from_fork+0x10/0x20------------[ cut here ]------------kernel BUG at mm/filemap.c:1563! folio_end_read+0x140/0x168 f2fs_finish_read_bio+0x5c4/0xb80 f2fs_read_end_io+0x64c/0x708 bio_endio+0x85c/0x8c0 blk_update_request+0x690/0x127c scsi_end_request+0x9c/0xb8c scsi_io_completion+0xf0/0x250 scsi_finish_command+0x430/0x45c scsi_complete+0x178/0x6d4 blk_mq_complete_request+0xcc/0x104 scsi_done_internal+0x214/0x454 scsi_done+0x24/0x34which is similar to the problem reported by syzbot:https://syzkaller.appspot.com/bug?extid=3686758660f980b402dcThis case is consistent with the description in commit 9bf1a3f("f2fs: avoid GC causing encrypted file corrupted"):Page 1 is moved from blkaddr A to blkaddr B by move_data_block, and afterbeing written it is marked as uptodate. Then, Page 1 is moved from blkaddrB to blkaddr C, VM_BUG_ON_FOLIO was triggered in the endio initiated byra_data_block.There is no need to read Page 1 again from blkaddr B, since it has alreadybeen updated. Therefore, avoid initiating I/O in this case.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: core: Fix integer overflow in UNMAP bounds checksbc_execute_unmap() checks LBA + range does not exceed the device capacity,but does not guard against LBA + range wrapping around on 64-bit overflow.Add an overflow check matching the pattern already used for WRITE_SAME inthe same file.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: terminate the cached volume label after UTF-8 conversionntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()and stores the result in sbi->volume.label. The converted label is laterexposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() onlyreturns the number of bytes written and does not add a trailing NUL.If the converted label fills the entire fixed buffer,ntfs3_label_show() can read past the end of sbi->volume.label whilelooking for a terminator.Terminate the cached label explicitly after a successful conversion andclamp the exact-full case to the last byte of the buffer.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:greybus: raw: fix use-after-free if write is called after disconnectIf a user writes to the chardev after disconnect has been called, thekernel panics with the following trace (withCONFIG_INIT_ON_FREE_DEFAULT_ON=y): BUG: kernel NULL pointer dereference, address: 0000000000000218 ... Call Trace: gb_operation_create_common+0x61/0x180 gb_operation_create_flags+0x28/0xa0 gb_operation_sync_timeout+0x6f/0x100 raw_write+0x7b/0xc7 [gb_raw] vfs_write+0xcf/0x420 ? task_mm_cid_work+0x136/0x220 ksys_write+0x63/0xe0 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7fDisconnect calls gb_connection_destroy, which ends up freeing theconnection object. When gb_operation_sync is called in the write fileoperations, its gets a freed connection as parameter and the kernelpanics.The gb_connection_destroy cannot be moved out of the disconnectfunction, as the Greybus subsystem expect all connections belonging to abundle to be destroyed when disconnect returns.To prevent this bug, use a rw lock to synchronize access between writeand disconnect. This guarantees that the write function doesn't tryto use a disconnected connection.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:greybus: raw: fix use-after-free on cdev closeThis addresses a use-after-free bug when a raw bundle is disconnectedbut its chardev is still opened by an application. When the applicationreleases the cdev, it causes the following panic when init on free isenabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y): refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130 ... Call Trace: cdev_put+0x18/0x30 __fput+0x255/0x2a0 __x64_sys_close+0x3d/0x80 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe cdev is contained in the "gb_raw" structure, which is freed in thedisconnect operation. When the cdev is released at a later time,cdev_put gets an address that points to freed memory.To fix this use-after-free, convert the struct device from a pointer tobeing embedded, that makes the lifetime of the cdev and of this devicethe same. Then, use cdev_device_add, which guarantees that the devicewon't be released until all references to the cdev have been released.Finally, delegate the freeing of the structure to the device releasefunction, instead of freeing immediately in the disconnect callback.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix NULL deref in map_kptr_match_type for scalar regsCommit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with localkptr") refactored map_kptr_match_type() to branch on btf_is_kernel()before checking base_type(). A scalar register stored into a kptrslot has no btf, so the btf_is_kernel(reg->btf) call dereferencesNULL.Move the base_type() != PTR_TO_BTF_ID guard before any reg->btfaccess.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix af_unix iter deadlockbpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fastpath and the iter prog attempts to update a sockmap. Which ends up spinningat sock_map_update_elem()'s bh_lock_sock():WARNING: possible recursive locking detectedtest_progs/1393 is trying to acquire lock:ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0but task is already holding lock:ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: prevent NULL pointer dereference during unmountWhen flushing out outstanding glock work during an unmount, gfs2_log_flush()can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdescis NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference ingfs2_log_flush") added a check for that to gfs2_log_flush() itself, but itmissed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache metadata: fix memory leak on metadata abort retryWhen failing to acquire the root_lock in dm_cache_metadata_abort becausethe block_manager is read-only, the temporary block_manager createdoutside the root_lock is not properly released, causing a memory leak.Reproduce steps:This can be reproduced by reloading a new table while the metadatais read-only. While the second call to dm_cache_metadata_abort iscaused by lack of support for table preload in dm-cache, mentionedin commit 9b1cc9f251af ("dm cache: share cache-metadata object acrossinactive and active DM tables"), it exposes the memory leak indm_cache_metadata_abort when the function is called multiple times.Specifically, dm-cache fails to sync the new cache object's mode duringpreresume, creating the reproducer condition.This issue could also occur through concurrent metadata_operation_failedcalls due to races in cache mode updates, but the table preload scenariobelow provides a reliable reproducer.1. Create a cache device with some faulty trailing metadata blocksdmsetup create cmeta <unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix null-deref with concurrent writes in passthrough modeIn passthrough mode, when dm-cache starts to invalidate a cacheentry and bio prison cell lock fails due to concurrent write tothe same cached block, mg->cell remains NULL. The error path ininvalidate_complete() attempts to unlock and free the cellunconditionally, causing a NULL pointer dereference:KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPTRIP: 0010:dm_cell_unlock_v2+0x3f/0x210Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870Reproduce steps:1. Create a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"dmsetup create corig --table "0 262144 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. Promote the first data block into cachefio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \--direct=1 --size=64k3. Reload the cache into passthrough modedmsetup suspend cachedmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0"dmsetup resume cache4. Write to the first cached block concurrentlyfio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \--randrepeat=0 --direct=1 --numjobs=2 --size 64kFix by checking if mg->cell is valid before attempting to unlock it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net, bpf: fix null-ptr-deref in xdp_master_redirect() for down mastersyzkaller reported a kernel panic in bond_rr_gen_slave_id() reached viaxdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPUcounter that bonding only allocates in bond_open() when the mode isround-robin. If the bond device was never brought up, rr_tx_counterstays NULL.The XDP redirect path can still reach that code on a bond that wasnever opened: bpf_master_redirect_enabled_key is a global static key,so as soon as any bond device has native XDP attached, theXDP_TX -> xdp_master_redirect() interception is enabled for everyslave system-wide. The path xdp_master_redirect() ->bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() ->bond_rr_gen_slave_id() then runs against a bond that has norr_tx_counter and crashes.Fix this in the generic xdp_master_redirect() by refusing to call intothe master's ->ndo_xdp_get_xmit_slave() when the master device is notup. IFF_UP is only set after ->ndo_open() has successfully returned,so this reliably excludes masters whose XDP state has not been fullyinitialized. Drop the frame with XDP_ABORTED so the exception isvisible via trace_xdp_exception() rather than silently falling through.This is not specific to bonding: any current or future master thatdefers XDP state allocation to ->ndo_open() is protected.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: Restrict use of RDS/IB to the initial network namespacePrevent using RDS/IB in network namespaces other than the initial one.The existing RDS/IB code will not work properly in non-initial networknamespaces.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bcmgenet: fix off-by-one in bcmgenet_put_txcbThe write_ptr points to the next open tx_cb. We want to return thetx_cb that gets rewinded, so we must rewind the pointer first thenreturn the tx_cb that it points to. That way the txcb can be correctlycleaned up.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected tobe freed eventually by mt76_mcu_skb_send_msg(). However, currently ifan intermediate function fails before sending, the allocated skb isleaked.Specifically, mt76_connac_mcu_sta_wed_update() andmt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memoryleak in the error path.Fix this by explicitly freeing the skb in these error paths.Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak onmt7996_mcu_sta_key_tlv error") made a similar change.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encapThe bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev tocalculate the needed headroom: err = skb_cow_head(skb, len + LL_RESERVED_SPACE(skb_dst(skb)->dev));But skb->_skb_refdst may not be initialized when the skb is set up bybpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap functionin this scenario will trigger null pointer dereference, causing a kernelcrash as Yinhao reported:[ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 105.186382] #PF: supervisor read access in kernel mode[ 105.186388] #PF: error_code(0x0000) - not-present page[ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0[ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1[ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520[ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0[ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246[ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00[ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500[ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000[ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98[ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002[ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000[ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0[ 105.186499] PKRU: 55555554[ 105.186502] Call Trace:[ 105.186507] [ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40[ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49[ 105.186536] ? kvm_clock_get_cycles+0x18/0x30[ 105.186547] ? ktime_get+0x3c/0xa0[ 105.186554] bpf_test_run+0x195/0x320[ 105.186563] ? bpf_test_run+0x10f/0x320[ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0[ 105.186590] __sys_bpf+0x69c/0xa40[ 105.186603] __x64_sys_bpf+0x1e/0x30[ 105.186611] do_syscall_64+0x59/0x110[ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0[ 105.186649] RIP: 0033:0x7f166a97455dTemporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix memory leaks in beacon template setupThe functions ath11k_mac_setup_bcn_tmpl_ema() andath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templatesbut fail to free it when parameter setup returns an error.Since beacon templates must be released during normal execution, theymust also be released in the error handling paths to prevent memoryleaks.Fix this by using unified exit paths with proper cleanup in the respectiveerror paths.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix potential unbounded skb queuevirtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.virtio_transport_recv_enqueue() skips coalescing for packetswith VIRTIO_VSOCK_SEQ_EOM.If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,a very large number of packets can be queuedbecause vvs->rx_bytes stays at 0.Fix this by estimating the skb metadata size: (Number of skbs in the queue) * SKB_TRUESIZE(0)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Skip CSD when it has zeroed workgroupsA compute shader dispatch encodes its workgroup counts in the CFG0..CFG2registers. Kicking off a dispatch with a zero count in any of the threedimensions is invalid. First, the hardware will process 0 as 65536,while the user-space driver exposes a maximum of 65535. Over that, asubmission with a zeroed workgroup dimension should be a no-op.These zeroed counts can reach the dispatch path through an indirect CSDjob, whose workgroup counts are only known once the indirect buffer isread and may legitimately be zero, but such scenario should only result ina no-op.Overwrite the indirect CSD job workgroup counts with the indirect BOones, even if they are zeroed, and don't submit the job to the hardwarewhen any of the workgroup counts is zero, so the job completes immediatelyinstead of running the shader.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/display: fix oops in suspend/shutdown without displayThe xe driver keeps track of whether to probe display, and whetherdisplay hardware is there, using xe->info.probe_display. It gets set tofalse if there's no display after intel_display_device_probe(). However,the display may also be disabled via fuses, detected at a later time inintel_display_device_info_runtime_init().In this case, the xe driver does for_each_intel_crtc() on uninitializedmode config in xe_display_flush_cleanup_work(), leading to a NULLpointer dereference, and generally calls display code with display infocleared.Check for intel_display_device_present() afterintel_display_device_info_runtime_init(), and resetxe->info.probe_display as necessary. Also do unset_display_features()for completeness, although display runtime init has already donethat. This will need to be unified across all cases later.Move intel_display_device_info_runtime_init() call slightly earlier,similar to i915, to avoid a bunch of unnecessary setup for no displaycases.Note #1: The xe driver has no business doing low level display plumbinglike for_each_intel_crtc() to begin with. It all needs to happen indisplay code.Note #2: The actual bug is present already in commit 44e694958b95("drm/xe/display: Implement display support"), but the oops was likelyintroduced later at commit ddf6492e0e50 ("drm/xe/display: Make displaysuspend/resume work on discrete").(cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix the ACK parser to extract the SACK table for parsingFix modification of the received skbuff in rxrpc_input_soft_acks() and apotential incorrect access of the buffer in a fragmented UDP packet (thepacket would probably have to be deliberately pre-generated as fragmented)when AF_RXRPC tries to extract the contents of the SACK table by copyingout the contents of the SACK table into a buffer before attempting to parseAF_RXRPC assumes that it can just call skb_condense() and then validlyaccess the SACK table from skb->data and that it will be a flat buffer -but skb_condense() can silently fail to do anything under somecircumstances.Note that whilst rxrpc_input_soft_acks() should be able to parse extendedACKs, the rest of AF_RXRPC doesn't currently support that.Further, there's then no need to call skb_condense() in rxrpc_input_ack(),so don't.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: core: fix use-after-free bugs in error pathsFix several instances of error paths in which we call__nvmem_device_put() - which may end up freeing the underlying memoryand other resources - and then keep on using the nvmem structure. Alwaysput the reference to the nvmem device as the last step before returningthe error code.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phonet: free phonet_device after RCU grace periodphonet_device_destroy() removes a phonet_device from the per-net devicelist with list_del_rcu(), but frees it immediately. RCU readers walkingthe same list can still hold a pointer to the object after it has beenremoved, leading to a slab-use-after-free.Use kfree_rcu(), matching the lifetime rule already used byphonet_address_del() for the same object type.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/rtmutex: Skip remove_waiter() when waiter is not enqueuedsyzbot triggered the following splat in remove_waiter() viaFUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection,leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task insteadof current in remove_waiter()") made this fatal.Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter()upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlockreturn correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock()(where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check toaccount for try_to_take_rt_mutex().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlockWhen FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns thetarget PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before settingwaiter->task.The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferencesthe NULL waiter->task, causing a kernel crash.Add a self-deadlock check for non-top waiters before callingrt_mutex_start_proxy_lock(), analogous to the top-waiter check infutex_lock_pi_atomic().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix buffer over-read in rtw_update_protectionrtw_update_protection() is called with a pointer offset into theies buffer but the full ie_length is passed, causing a potentialbuffer over-read.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: allow subflow rcv wnd to shrinkIn MPTCP connection, the `window` field in the TCP header refers to theMPTCP-level rcv_nxt and it's right edge should not move backward. Suchconstraint is enforced at DSS option generation time.At the same time, the TCP stack ensures independently that the TCP-levelrcv wnd right's edge does not move backward. That in turn causes artificialinflating of the MPTCP rcv window when the incoming data is acked at theTCP level and is OoO in the MPTCP sequence space (or lands in the backlog).As a consequence, the incoming traffic can exceed the receiver rcvbuf sizeeven when the sender is not misbehaving.Prevent such scenario forcibly allowing the TCP subflow to shrink theTCP-level rcv wnd regardless of the current netns setting.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retriesWhen a bundle recv retries inside io_recv_finish(), the merge logic ORthe saved cflags from the previous iteration with the cflags returned bythe new iteration: cflags = req->cqe.flags | (cflags & CQE_F_MASK);Bits listed in CQE_F_MASK are inherited from the new iteration, and allother bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from thesaved cflags. Before this change CQE_F_MASK covered onlyIORING_CQE_F_SOCK_NONEMPTY and IORING_CQE_F_MORE.When using provided buffer rings (IOU_PBUF_RING_INC) with incrementalmode, and bundle recv, io_kbuf_inc_commit() can leave the head ringentry partially consumed, __io_put_kbufs() then setsIORING_CQE_F_BUF_MORE on the returned cflags so userspace knows thebuffer ID will be reused for subsequent completions.Because IORING_CQE_F_BUF_MORE was not in CQE_F_MASK, the merge abovesilently dropped it whenever the final retry iteration partiallyconsumed the buffer, and the subsequent req->cqe.flags = cflags &~CQE_F_MASK save would have left a stale IORING_CQE_F_BUF_MORE in thecarried-over cflags had one been present. Userspace would thenwrongfully advance it ring head past an entry the kernel still uses.Add IORING_CQE_F_BUF_MORE to CQE_F_MASK so it is both inherited from thenew iteration into the user-visible CQE and stripped from the savedcflags between iterations.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: use kmap_local_page in netvsc_copy_to_send_bufnetvsc_copy_to_send_buf() copies page buffer entries into the VMBussend buffer using phys_to_virt() on the entry PFN. Entries for theRNDIS header and the skb linear data come from kmalloc'd memory andare always in the kernel direct map, but entries for skb fragmentsreference page cache or user pages, which on 32-bit x86 withCONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a pagephys_to_virt() returns an address outside the direct map and thesubsequent memcpy() faults on the transmit softirq path, which isfatal.Map the pages with kmap_local_page() instead, handling two propertiesof the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries.The copy path only handles packets smaller than the send section size(6144 bytes by default); larger packets take the cp_partial path whereonly the RNDIS header is copied. So entries here are bounded by thesection size and a copy is split at most once on 4K-page systems. On!CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() andno mapping work is added.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_exthdr: fix register tracking for F_PRESENT flagnft_exthdr_init() passes user-controlled priv->len tonft_parse_register_store(), which marks that many bytes in theregister bitmap as initialized. However, when NFT_EXTHDR_F_PRESENTis set, the eval paths write only 1 byte (nft_reg_store8) or4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4,registers beyond the first are never written, retaininguninitialized stack data from nft_regs.Bail out if userspace requests too much data when F_PRESENT is set.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: revalidate bridge portsebt_redirect_tg() dereferences br_port_get_rcu() return without aNULL check, causing a kernel panic when the bridge port has beenremoved between the original hook invocation and an NFQUEUEreinject.A mere NULL check isn't sufficient, however. As sashiko reviewpoints out userspace can not only remove the port from the bridge,it could also place the device in a different virtual device, e.g.macvlan.If this happens, we must drop the packet, there is no way for us toreinject it into the bridge path.Switch to _upper API, we don't need the bridge port structure.Also, this fix keeps another bug intact:Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTERtoo aggressive, which prevents certain logging features when queueingin bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the oldCONFIG_BRIDGE_NETFILTER cruft is off.Fixes tag is a common ancestor, this was always broken.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()In vti6_tnl_lookup(), when an exact match for a tunnel fails,the code falls back to searching for wildcard tunnels:- Tunnels matching the packet's local address, with any remote address wildcard remote).- Tunnels matching the packet's remote address, with any local address (wildcard local).However, vti6 stores all these different types of tunnels in the samehash table (ip6n->tnls_r_l) prone to hash collisions.The bug is that the fallback search loops in vti6_tnl_lookup() weremissing checks to ensure that the candidate tunnel actually hasa wildcard address.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: guard timestamp cmsgs to real error queue skbsskb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skbfrom sk_error_queue. That assumption is not true for AF_PACKET sockets:outgoing packet taps are also delivered to packet sockets withskb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKETinstead of struct sock_exterr_skb.If such an skb is received with timestamping enabled, the generictimestamp cmsg path can read AF_PACKET control-buffer state assock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet dropcounter overlaps opt_stats. An odd drop count makes the path emitSCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linearskbs this copies past the linear head and can trigger hardened usercopy ordisclose adjacent heap contents.Keep skb_is_err_queue() local to net/socket.c, but make it verify thatthe PACKET_OUTGOING marker is paired with the sock_rmem_free destructorinstalled by sock_queue_err_skb(). AF_PACKET receive skbs use normalreceive ownership and no longer pass as error-queue skbs, while legitimatesk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_freeownership.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: rockchip: fix generic IRQ chip leak on removeThe driver allocates domain generic chips usingirq_alloc_domain_generic_chips() during probe. However, on driverremove/teardown, the generic chips are not automatically freed when theIRQ domain is removed because the domain flags do not includeIRQ_DOMAIN_FLAG_DESTROY_GC.This causes both the domain generic chips structure and the associatedgeneric chips to be leaked. Additionally, the generic chips remain onthe global gc_list and may later be visited by generic IRQ chip suspend,resume, or shutdown callbacks after the GPIO bank has been removed,potentially resulting in a use-after-free and kernel crash.Fix the resource leak by explicitly callingirq_domain_remove_generic_chips() before removing the IRQ domain inrockchip_gpio_remove().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sit: reload inner IPv6 header after GSO offloadsipip6_tunnel_xmit() caches the inner IPv6 header pointer at functionentry and continues using it after iptunnel_handle_offloads().For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone().When the skb header is cloned, skb_header_unclone() can callpskb_expand_head(), which may move the skb head. The pskb_expand_head()contract requires pointers into the skb header to be reloaded after thecall.If the later skb_realloc_headroom() branch is not taken, SIT uses thestale iph6 pointer to read the inner hop limit and DS field. That canread from a freed skb head after the old head's remaining clone isreleased.Reload iph6 after the offload helper succeeds and before subsequentreads from the inner IPv6 header. Keep the existing reload afterskb_realloc_headroom(), since that branch can also replace the skb.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_listmlx5_query_nic_vport_mac_list() sizes its firmware command buffer usingthe PF's log_max_current_uc/mc_list capabilities. When querying a VFvport with a larger configured max (via devlink), the firmware responsecan overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly.Refactor the function to allocate and return the MAC list internally,removing the caller's dependency on knowing the correct max.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardownmtk_free_dev() calls metadata_dst_free() which frees the metadata_dstwith kfree() immediately, bypassing the RCU grace period.In the RX path, skb_dst_set_noref() sets a non-refcounted pointer fromthe skb to the metadata_dst. This function requires RCU read-sideprotection and the dst must remain valid until all RCU readers complete.Since metadata_dst_free() calls kfree() directly, a use-after-free canoccur if any skb still holds a noref pointer to the dst when the drivertears it down.Replace metadata_dst_free() with dst_release() which properly goesthrough the refcount path: when the refcount drops to zero, it schedulesthe actual free via call_rcu_hurry(), ensuring all RCU readers havecompleted before the memory is freed.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: fix memory leak in error path of hci_alloc_dev()Early failures in Bluetooth HCI UART configuration leak SRCU percpumemory.When device initialization fails before hci_register_dev() completes,the HCI_UNREGISTER flag is never set. As a result, when the devicereference count reaches zero, bt_host_release() evaluates this flag asfalse and falls back to a direct kfree(hdev).Because hci_release_dev() is bypassed, the SRCU struct initializedearly in hci_alloc_dev() is never cleaned up, resulting in a leak ofpercpu memory.Fix the leak by explicitly calling cleanup_srcu_struct() in thefallback (unregistered) branch of bt_host_release() before freeingthe device.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: fix leak if split 6 GHz scanning failsrdev->int_scan_req is leaked if cfg80211_scan() fails. Note that it'ssupposed to be released at ___cfg80211_scan_done() but this doesn't happenas rdev->scan_req is NULL at that point, too, leading to the early returnfrom the freeing function.unreferenced object 0xffff8881161d0800 (size 512): comm "wpa_supplicant", pid 379, jiffies 4294749765 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 f0 81 13 16 81 88 ff ff ................ backtrace (crc c867fdb6): kmemleak_alloc+0x89/0x90 __kmalloc_noprof+0x2fd/0x410 cfg80211_scan+0x133/0x730 nl80211_trigger_scan+0xc69/0x1cc0 genl_family_rcv_msg_doit+0x204/0x2f0 genl_rcv_msg+0x431/0x6b0 netlink_rcv_skb+0x143/0x3f0 genl_rcv+0x27/0x40 netlink_unicast+0x4f6/0x820 netlink_sendmsg+0x797/0xce0 __sock_sendmsg+0xc4/0x160 ____sys_sendmsg+0x5e4/0x890 ___sys_sendmsg+0xf8/0x180 __sys_sendmsg+0x136/0x1e0 __x64_sys_sendmsg+0x76/0xc0 x64_sys_call+0x13f0/0x17d0Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_api: use RCU with deferred freeing for action lifecycleWhen NEWTFILTER and DELFILTER are run concurrently it is possible to create arace with an associated action.Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memoryThis patch fixes the race condition between NEWTFILTER and DELFILTER byadding struct rcu_head to tc_action used in the deferral and introducing acall_rcu() in the delete path to defer the final kfree().Note: this is a revert of commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu")but also modernization/simplification to directly use kfree_rcu().Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace periodAfter CPU1 calls idr_remove(), the object is no longer reachable through the IDR.CPU0's subsequent idr_find() will return NULL, and even if it still held astale pointer, the immediate kfree() is now deferred until after the RCU graceperiod, so no UAF can occur.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack_irc: fix possible out-of-bounds readWhen parsing fails after we've matched the command string weshould bail out instead of trying to match a different command.This helper should be deprecated, given prevalence of TLS I doubt it hasany relevance in 2026.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: clear the svc scheduler ptr early on editip_vs_edit_service() while unbinding the old scheduler clearsthe svc->scheduler ptr after the scheduler module initiatesRCU callbacks. This can cause packets to use the oldscheduler at the time when svc->sched_data is already freedafter RCU grace period.Fix it by clearing the ptr early in ip_vs_unbind_scheduler(),before the done_service method schedules any RCU callbacks.Also, if the new scheduler fails to initialize when replacingthe old scheduler, try to restore the old scheduler while stillreturning the error code.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Avoid NULL pointer dereference or refcount corruptionCommit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE")fixed a NULL pointer dereference in an unlikely situation partly.If dev_pasid is not found in the dev_pasids list, it remains NULL.However, the teardown operations are executed unconditionally, this leadto a NULL pointer dereference or refcount corruption.If the domain was never attached to this IOMMU, info will be NULL, whichwould cause an immediate dereference when checking --info->refcnt.Even if info is not NULL, decrementing the refcount without having removeda valid PASID might unbalance the count. This could lead to prematuredropping of the refcount to 0, potentially causing a use-after-free for theremaining active devices sharing the domain.Fix it by returning early if dev_pasid is NULL, before executing theteardown operations.Issue found by AI review and suggested by Kevin Tian.https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED[Why]dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() withDC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(),which disables local softirqs.The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() toallocate ~335 KiB for dc_plane_state. This triggers the vmalloc path,which calls BUG_ON(in_interrupt()) because it's invoked within theFPU-enabled (softirq disabled) region, leading to a kernel crash.[How]Wrap the dc_state_create_phantom_plane() call with theDC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption duringthis memory allocation.(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: fix incorrect inheritable capability in CAPSET records__audit_log_capset() records the effective capability set into theinheritable field due to a copy-paste error. Every CAPSET auditrecord therefore reports cap_pi (process inheritable) with the valueof cap_effective instead of cap_inheritable.This silently corrupts audit data used for compliance and forensicanalysis: an attacker who modifies inheritable capabilities toprepare for a privilege-escalating exec would have the change maskedin the audit trail.The bug has been present since the original introduction of CAPSETaudit records in 2008.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bindsyzbot reported a kernel BUG triggered from pn_socket_sendmsg() viapn_socket_autobind(): kernel BUG at net/phonet/socket.c:213! RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline] RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: sock_sendmsg_nosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] __sys_sendto+0x402/0x590 net/socket.c:2280 ...pn_socket_autobind() calls pn_socket_bind() with port 0 and, on-EINVAL, assumes the socket was already bound and asserts that theport is non-zero: err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn)); if (err != -EINVAL) return err; BUG_ON(!pn_port(pn_sk(sock->sk)->sobject)); return 0; /* socket was already bound */However pn_socket_bind() also returns -EINVAL when sk->sk_state is notTCP_CLOSE, even when the socket has never been bound and pn_port() isstill 0. In that case the BUG_ON() fires and panics the kernel from auser-triggerable path.Treat the "bind returned -EINVAL but pn_port() is still 0" case as aregular error and propagate -EINVAL to the caller instead of crashing.Existing callers already translate a non-zero return frompn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL hereonly changes behaviour from panic to a normal errno.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: add sanity check for channel arrayFail gracefully if there is no channel array attached to the mailboxcontroller. Otherwise the later dereference will cause an OOPS whichmight not be seen because mailbox controllers might instantiate veryearly. Remove the comment explaining the obvious while here.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: mailbox-test: free channels on probe errorOn probe error, free the previously obtained channels. This not onlyprevents a leak, but also UAF scenarios because the client structurewill be removed nonetheless because it was allocated with devm.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show()In f2fs_sbi_show(), the extension_list, extension_count andhot_ext_count are read without holding sbi->sb_lock. If a concurrentsysfs store modifies the extension list via f2fs_update_extension_list(),the show path may read inconsistent count and array contents, potentiallyleading to out-of-bounds access or displaying stale data.Fix this by holding sb_lock around the entire extension list readand format operation.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Resolve soft lockup issue when opening /dev/sgXThe parameter def_reserved_size defines the default buffer size reservedfor each Sg_fd and should be restricted to a range between 0 and 1,048,576(see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although thefunction sg_proc_write_dressz enforces this limit, it is possible to bypassit by directly modifying the module parameter as shown below, which thencauses a soft lockup:echo -1 > /sys/module/sg/parameters/def_reserved_sizeexec 4<> /dev/sg0watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537]Modules loaded:CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134,PREEMPT disabledHardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version1.16.1-2.fc37 dated 04/01/2014...Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe fix is to use module_param_cb to validate and reject invalid valuesassigned to def_reserved_size.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: Place upper limit on station AIDAny station configured with an AID over 20 causes a firmware crash.This situation occurred in our testing using an AP interface on 7922hardware, with a modified hostapd, sourced from Mediatek's OpenWRTfeeds.In stock hostapd, station AIDs begin counting at 1, and thisconfiguration is prevented with an upper limit on associated stations.However, the modified hostapd began allocation at 65, which caused thefirmware to crash. This fix does not allow these AIDs to work, but willprevent the firmware crash.This crash was only seen on IFTYPE_AP interfaces, and the fix does notappear to have an effect on IFTYPE_STATION behavior.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd > 0-0 (version in image is 1.7.29-150000.132.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- tar > 0-0 (version in image is 1.34-150000.3.37.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05!method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node's Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libefivar1 > 0-0 (version in image is 37-6.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloadsatomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.cunconditionally dereferences 8 bytes at payload_addr(pkt): value = *(u64 *)payload_addr(pkt);check_rkey() previously accepted an ATOMIC_WRITE request with pktlen ==resid == 0 because the length validation only compared pktlen againstresid. A remote initiator that sets the RETH length to 0 therefore reachesatomic_write_reply() with a zero-byte logical payload, and the responderreads sizeof(u64) bytes from past the logical end of the packet intoskb->head tailroom, then writes those 8 bytes into the attacker's MR viarxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kerneltailroom per probe (the other 4 bytes are the packet's own trailing ICRC).IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else isprotocol-invalid. Hoist a strict length check into check_rkey() so theresponder never reaches the unchecked dereference, and keep the existingWRITE-family length logic for the normal RDMA WRITE path.Reproduced on mainline with an unmodified rxe driver: a sustainedzero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-bufferbytes into the attacker's MR, including recognisable kernel strings andpartial kernel-direct-map pointer words. With this patch applied theresponder rejects the PDU and the MR stays all-zero.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).
-
Description: nghttp2's nghttpx proxy through 1.69.0 forwards an HTTP/1.1 Upgrade request that also carries a Content-Length header and body onto reusable keep-alive backend connections, re-adding the Upgrade and Connection headers while passing Content-Length verbatim. A backend that resolves the resulting ambiguous message in the attacker's favor enables HTTP request/response smuggling and cross-client response-queue poisoning.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libnghttp2-14 > 0-0 (version in image is 1.64.0-150700.3.3.1).
-
Description: Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.4.24, 0.5.14, and 0.6.4, symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands. This issue has been patched in versions 0.4.24, 0.5.14, and 0.6.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150700.24.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure no dirty metadata is written back for an fs with errors[BUG]During development of a minor feature (make sure all btrfs_bio::end_io()is called in task context), I noticed a crash in generic/388, wheremetadata writes triggered new works after btrfs_stop_all_workers().It turns out that it can even happen without any code modification, justusing RAID5 for metadata and the same workload from generic/388 is goingto trigger the use-after-free.[CAUSE]If btrfs hits an error, the fs is marked as error, no newtransaction is allowed thus metadata is in a frozen state.But there are some metadata modifications before that error, and they arestill in the btree inode page cache.Since there will be no real transaction commit, all those dirty foliosare just kept as is in the page cache, and they can not be invalidatedby invalidate_inode_pages2() call inside close_ctree(), because they aredirty.And finally after btrfs_stop_all_workers(), we call iput() on btreeinode, which triggers writeback of those dirty metadata.And if the fs is using RAID56 metadata, this will trigger RMW and queuenew works into rmw_workers, which is already stopped, causing warningfrom queue_work() and use-after-free.[FIX]Add a special handling for write_one_eb(), that if the fs is already inan error state, immediately mark the bbio as failure, instead of reallysubmitting them.Then during close_ctree(), iput() will just discard all those dirtytree blocks without really writing them back, thus no more new jobs foralready stopped-and-freed workqueues.The extra discard in write_one_eb() also acts as an extra safenet.E.g. the transaction abort is triggered by some extent/free spacetree corruptions, and since extent/free space tree is already corruptedsome tree blocks may be allocated where they shouldn't be (overwritingexisting tree blocks). In that case writing them back will furthercorrupting the fs.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent > 0-0 (version in image is 3.3.1611.0-150000.5.26.1).
-
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker < 29.4.0_ce-150000.250.1 (version in image is 28.5.1_ce-150000.247.1).
-
Description: Socket versions before 2.041 for Perl have an out-of-bounds heap read.In Socket.xs, pack_ip_mreq_source() checks the length of its source argument before the argument is read, so the check tests the byte length carried over from the preceding multiaddr argument instead. Both addresses occupy a 4-byte field, so a valid multiaddr lets a source of any length pass the check, and the source is then copied into the 4-byte imr_sourceaddr field with a fixed-size copy. A source shorter than 4 bytes is not rejected, and the copy reads up to 3 bytes past the end of its buffer.Calling pack_ip_mreq_source() with a source value shorter than 4 bytes copies adjacent heap memory into the returned packed structure.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- perl > 0-0 (version in image is 5.26.1-150300.17.20.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Sanitize payload size to prevent member overflowIn qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_sizereported by firmware is used to calculate the copy length intoitem->iocb. However, the iocb member is defined as a fixed-size 64-bytearray within struct purex_item.If the reported frame_size exceeds 64 bytes, subsequent memcpy calls willoverflow the iocb member boundary. While extra memory might be allocated,this cross-member write is unsafe and triggers warnings underCONFIG_FORTIFY_SOURCE.Fix this by capping total_bytes to the size of the iocb member (64 bytes)before allocation and copying. This ensures all copies remain within thebounds of the destination structure member.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix __perf_event_overflow() vs perf_remove_from_context() raceMake sure that __perf_event_overflow() runs with IRQs disabled for allpossible callchains. Specifically the software events can end up runningit with only preemption disabled.This opens up a race vs perf_event_exit_event() and friends that will goand free various things the overflow path expects to be present, likethe BPF program.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS caseIn decode_int(), the CONS case calls get_bits(bs, 2) to read a lengthvalue, then calls get_uint(bs, len) without checking that len bytesremain in the buffer. The existing boundary check only validates the2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()reads. This allows a malformed H.323/RAS packet to cause a 1-4 byteslab-out-of-bounds read.Add a boundary check for len bytes after get_bits() and beforeget_uint().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()sip_help_tcp() parses the SIP Content-Length header withsimple_strtoul(), which returns unsigned long, but stores the result inunsigned int clen. On 64-bit systems, values exceeding UINT_MAX aresilently truncated before computing the SIP message boundary.For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,causing the parser to miscalculate where the current message ends. Theloop then treats trailing data in the TCP segment as a second SIPmessage and processes it through the SDP parser.Fix this by changing clen to unsigned long to match the return type ofsimple_strtoul(), and reject Content-Length values that exceed theremaining TCP payload length.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: 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]Also note that we do not enable the driver_override feature of structbus_type, as SPI - in contrast to most other buses - passes "" tosysfs_emit() when the driver_override pointer is NULL. Thus, printing"\n" instead of "(null)\n".
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timerand id_addr_timer while holding conn->lock. However, the work functionsl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquireconn->lock, creating a potential AB-BA deadlock if the work is alreadyexecuting when l2cap_conn_del() takes the lock.Move the work cancellations before acquiring conn->lock and usedisable_delayed_work_sync() to additionally prevent the works frombeing rearmed after cancellation, consistent with the pattern used inhci_conn_del().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:writeback: Fix use after free in inode_switch_wbs_work_fn()inode_switch_wbs_work_fn() has a loop like: wb_get(new_wb); while (1) { list = llist_del_all(&new_wb->switch_wbs_ctxs); /* Nothing to do? */ if (!list) break; ... process the items ... }Now adding of items to the list looks like:wb_queue_isw() if (llist_add(&isw->list, &wb->switch_wbs_ctxs)) queue_work(isw_wq, &wb->switch_work);Because inode_switch_wbs_work_fn() loops when processing isw items, itcan happen that wb->switch_work is pending while wb->switch_wbs_ctxs isempty. This is a problem because in that case wb can get freed (no iswitems -> no wb reference) while the work is still pending causinguse-after-free issues.We cannot just fix this by cancelling work when freeing wb because thatcould still trigger problematic 0 -> 1 transitions on wb refcount due towb_get() in inode_switch_wbs_work_fn(). It could be all handled withmore careful code but that seems unnecessarily complex so let's avoidthat until it is proven that the looping actually brings practicalbenefit. Just remove the loop from inode_switch_wbs_work_fn() instead.That way when wb_queue_isw() queues work, we are guaranteed we haveadded the first item to wb->switch_wbs_ctxs and nobody is going toremove it (and drop the wb reference it holds) until the queued workruns.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: When calling base64.b64decode() or related functions the decoding process would stop after encountering the first padded quad regardless of whether there was more information to be processed. This can lead to data being accepted which may be processed differently by other implementations. Use "validate=True" to enable stricter processing of base64 data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_11-1_0 < 3.11.15-150600.3.56.1 (version in image is 3.11.15-150600.3.53.1).
-
Description: BIND resolvers are vulnerable to an amplified resource consumption/exhaustion attack. If a victim resolver makes a query to a specially crafted zone, the resolver will consume disproportionate resources.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- bind-utils < 9.20.23-150700.3.25.1 (version in image is 9.20.21-150700.3.18.1).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]To create and manage guests, domctl operations are used by the controldomain, a possible Xenstore domain, or by a domain controlling aparticular guest. Some of these operations may not be executed inparallel, so a system-wide lock is used. The way that lock is acquiredis, however, not providing any fairness. This is CVE-2026-42489.Furthermore, with XSM/Flask in use, the lock acquire will, for someoperations, occur ahead of any permission checking. This isCVE-2026-42490.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- xen-libs < 4.20.3_06-150700.3.41.1 (version in image is 4.20.3_04-150700.3.36.1).
-
Description: Issue summary: Receiving a QUIC initial packet with an invalid token maytrigger a NULL pointer dereference in the OpenSSL QUIC server withaddress validation disabled.Impact summary: NULL pointer dereference typically causes abnormal terminationof the affected QUIC server process and a Denial of Service.If the address validation is disabled in the OpenSSL QUIC serverimplementation, an attacker can crash the server by sending an initialpacket with an invalid or expired token.By default, the client address validation is enabled in the OpenSSL QUIC serverimplementation, which makes the default configuration not vulnerableto this issue. However if the SSL_LISTENER_FLAG_NO_VALIDATE is used withthe SSL_new_listener() call, the address validation is disabled making thevulnerable code reachable.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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 > 0-0 (version in image is 3.2.3-150700.5.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md-cluster: fix NULL pointer dereference in process_metadata_updateThe function process_metadata_update() blindly dereferences the 'thread'pointer (acquired via rcu_dereference_protected) within the wait_event()macro.While the code comment states "daemon thread must exist", there is a validrace condition window during the MD array startup sequence (md_run):1. bitmap_load() is called, which invokes md_cluster_ops->join().2. join() starts the "cluster_recv" thread (recv_daemon).3. At this point, recv_daemon is active and processing messages.4. However, mddev->thread (the main MD thread) is not initialized until later in md_run().If a METADATA_UPDATED message is received from a remote node during thisspecific window, process_metadata_update() will be called whilemddev->thread is still NULL, leading to a kernel panic.To fix this, we must validate the 'thread' pointer. If it is NULL, werelease the held lock (no_new_dev_lockres) and return early, safelyignoring the update request as the array is not yet fully ready toprocess it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't send a 6E related command when not supportedMCC_ALLOWED_AP_TYPE_CMD is related to 6E support. Do not send it if thedevice doesn't support 6E.Apparently, the firmware is mistakenly advertising support for thiscommand even on AX201 which does not support 6E and then the firmwarecrashes.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Internationalized Domain Names in Applications (IDNA) for Python provides support for Internationalized Domain Names in Applications (IDNA) and Unicode IDNA Compatibility Processing. In versions prior to 3.15, payloads such as `"\u0660" * N` or `"\u30fb" * N + "\u6f22"` utilize the `valid_contexto` function prior to length rejection, and for high values of `N` will take a long time to process. This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. A specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service. Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). A workaround is available. Domain names cannot exceed 253 characters in length. If this length limit is enforced prior to passing the domain to the `idna.encode()` function, it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-idna > 0-0 (version in image is 2.6-150000.3.6.1).
-
Description: Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV(RFC 8452) mishandle the authentication of AAD (Additional AuthenticatedData) with an empty ciphertext allowing a forgery of such messages.Impact summary: An attacker can forge empty messages with arbitrary AADto the victim's application using these ciphers.AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEADmodes: they accept a key, nonce, optional AAD (bytes that are authenticatedbut not encrypted), and plaintext, and produces ciphertext plus a 16-bytetag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success onlyif the tag is verified succesfully.In OpenSSL's provider implementation of these ciphers, the expected tag iscomputed only when decryption function is invoked with non-empty data.If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` withoutinvocation of the ciphertext update, which can happen when the receivedciphertext length is zero, the tag is never recalculated and still holds itsall-zeros value.When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, emptyciphertext, and all-zeros tag passes authentication under any key they do notknow, single-shot. When AES-SIV is used, for mounting the attack it'snecessary for the application to reuse the decryption context withoutresetting the key.AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented sinceOpenSSL 3.2.No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) supporteither AES-GCM-SIV or AES-SIV. To mount an attack, the applications mustimplement their own protocol and use the EVP interface. Also they must skip theciphertext update when a message with an empty ciphertext arrives.The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by thisissue, as these algorithms are not FIPS approved and the affected code isoutside the OpenSSL FIPS module boundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: increase the connection clean up limit to 64After the optimization to only perform one GC per jiffy, a new problemwas introduced. If more than 8 new connections are tracked per jiffy thelist won't be cleaned up fast enough possibly reaching the limitwrongly.In order to prevent this issue, only skip the GC if it was alreadytriggered during the same jiffy and the increment is lower than theclean up limit. In addition, increase the clean up limit to 64connections to avoid triggering GC too often and do more effective GCs.This has been tested using a HTTP server and severalperformance tools while having nft_connlimit/xt_connlimit or OVS limitconfigured.Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix unlocked call to hns_roce_qp_remove()Sashiko points out that hns_roce_qp_remove() requires the caller to holdlocks. The error flow in hns_roce_create_qp_common() doesn't hold thoselocks for the error unwind so it risks corrupting memory.Grab the same locks the other two callers use.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:8021q: delete cleared egress QoS mappingsvlan_dev_set_egress_priority() currently keeps cleared egresspriority mappings in the hash as tombstones. Repeated set/clear cycleswith distinct skb priorities therefore accumulate mapping nodes untildevice teardown and leak memory.Delete mappings when vlan_prio is cleared instead of keeping tombstones.Now that the egress mapping lists are RCU protected, the node can beunlinked safely and freed after a grace period.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: oss: Fix data race at accessing runtime.oss.triggerCurrently the runtime.oss.trigger field may be accessed concurrentlywithout protection, which may lead to the data race. And, in thiscase, it may lead to more severe problem because it's a bit field; aswriting the data, it may overwrite other bit fields as well, whichconfuses the operation completely, as spotted by fuzzing.Fix it by covering runtime.oss.trigger bit fled also with the existingparams_lock mutex in both snd_pcm_oss_get_trigger() andsnd_pcm_oss_poll().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:MIPS: Work around LLVM bug when gp is used as global register variableOn MIPS, __current_thread_info is defined as global register variablelocating in $gp, and is simply assigned with new address during kernelrelocation.This however is broken with LLVM, which always restores $gp if it finds$gp is clobbered in any form, including when intentionally through aglobal register variable. This is against GCC's documentation[1], whichrequires a callee-saved register used as global register variable not tobe restored if it's clobbered.As a result, $gp will continue to point to the unrelocated kernel afterthe epilog of relocate_kernel(), leading to an early crash in init_idle,[ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90[ 0.000000] Oops[#1]:[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY[ 0.000000] Tainted: [W]=WARN[ 0.000000] Hardware name: loongson,loongson64v-4core-virtio[ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000[ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240[ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001[ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002[ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80[ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80[ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90[ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90[ 0.000000] Hi : 0000000000000000[ 0.000000] Lo : 0000000000000000[ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270[ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270[ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL[ 0.000000] Cause : 00000008 (ExcCode 02)[ 0.000000] BadVA : 0000000000000000[ 0.000000] PrId : 00006305 (ICT Loongson-3)[ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)[ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000[ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528[ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000[ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258[ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98[ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000[ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000[ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000[ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000[ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002[ 0.000000] ...[ 0.000000] Call Trace:[ 0.000000] [] init_idle+0x130/0x270[ 0.000000] [] sched_init+0x5c8/0x6c0[ 0.000000] [] start_kernel+0x27c/0x7a8This bug has been reported to LLVM[2] and affects version from (atleast) 18 to 21. Let's work around this by using inline assembly toassign $gp before a fix is widely available.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Free reuseport cBPF prog after RCU grace period.Eulgyu Kim reported the splat below with a repro. [0]The repro sets up a UDP reuseport group with a cBPF prog andreplaces it with a new one while another thread is sendinga UDP packet to the group.The reuseport prog is freed by sk_reuseport_prog_free().bpf_prog_put() is called for "e"BPF prog to destruct throughmultiple stages while cBPF prog is freed immediately bybpf_release_orig_filter() and bpf_prog_free().If a reuseport prog is detached from the setsockopt() path(reuseport_attach_prog() or reuseport_detach_prog()),sk_reuseport_prog_free() is called without waiting for RCUreaders to complete, resulting in various bugs.Let's defer freeing the reuseport cBPF prog after one RCUgrace period.Note "e"BPF prog is safe as is unless the fast path startsto touch fields destroyed in bpf_prog_put_deferred() and__bpf_prog_put_noref().[0]:BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596Read of size 4 at addr ffffc9000051e004 by task slowme/10208CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full)Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call 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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x415a2dCode: b3 66 2e 0f 1f 84 00 00 00 00 00 66 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2dRDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010R10: 0000000000000000 R11: ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: diag: reject stale associations in dump_one pathThe SCTP exact sock_diag lookup can hold a transport reference, block onlock_sock(sk), and then resume after sctp_association_free() has markedthe association dead and freed its bind address list.When that happens, inet_assoc_attr_size() andinet_diag_msg_sctpasoc_fill() can still dereference association statethat is no longer valid for reporting. In particular,inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as areal sctp_sockaddr_entry and trigger an out-of-bounds read fromunrelated association memory.Reject the association after taking the socket lock if it has beenreaped or detached from the endpoint, and report the lookup as stale.This keeps the exact dump-one path from formatting torn associationstate.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.2 and newer fail to enforce the caller-supplied buffer length, and can result in an out-of-bounds write when printing TSIG records.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc > 0-0 (version in image is 2.38-150600.14.46.1).
-
Description: An unbounded resend loop vulnerability exists in the BIND 9 resolver state machine during bad-server handling, enabling a remote unauthenticated attacker to cause severe resource exhaustion by sending queries that trigger specific retry conditions.This issue affects BIND 9 versions 9.18.36 through 9.18.48, 9.20.8 through 9.20.22, 9.21.7 through 9.21.21, 9.18.36-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- bind-utils < 9.20.23-150700.3.25.1 (version in image is 9.20.21-150700.3.18.1).
-
Description: The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.0.1 to version 2.43 fail to validate the RDATA content against the RDATA length in a DNS response when processing A6, CERT, LOC, TKEY or TSIG records, which may allow an attacker to craft a DNS response, causing a target application to crash or read uninitialized memory.These functions are for application debugging only and hence not in the path of code executed by the DNS resolver. Further, they have been deprecated since version 2.34 and should not be used by any new applications. Applications should consider porting away from these interfaces since they may be removed in future versions.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc > 0-0 (version in image is 2.38-150600.14.46.1).
-
Description: The ftpcp() function in Lib/ftplib.py was not updated when CVE-2021-4189 was fixed. While makepasv() was patched to replace server-supplied PASV host addresses with the actual peer address (getpeername()[0]), ftpcp() still calls parse227() directly and passes the raw attacker-controllable IP address and port to target.sendport(). This patch is related to CVE-2021-4189.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Prevent lockup in requeue-PI during signal/ timeout wakeupDuring wait-requeue-pi (task A) and requeue-PI (task B) the followingrace can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry*Task B acquires both hb locks and attempts to acquire the PI-lock of thetop most waiter (task B). Task A is leaving early due to a signal/timeout and started removing itself from the queue. It updates itsrequeue_state but can not remove it from the list because this requiresthe hb lock which is owned by task B.Usually task A is able to swoop the lock after task B unlocked it.However if task B is of higher priority then task A may not be able towake up in time and acquire the lock before task B gets it again.Especially on a UP system where A is never scheduled.As a result task A blocks on the lock and task B busy loops, trying tomake progress but live locks the system instead. Tragic.This can be fixed by removing the top most waiter from the list in thiscase. This allows task B to grab the next top waiter (if any) in thenext iteration and make progress.Remove the top most waiter if futex_requeue_pi_prepare() fails.Let the waiter conditionally remove itself from the list inhandle_early_requeue_pi_wakeup().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42)peer key, the peer key is not properly checked for the subgroup membership.Impact summary: A malicious peer which presents an X9.42 key carrying thevictim's p and g parameters, a forged q = r (a small prime factor of thecofactor (p−1)/q_local), and a public value Y of order r can recover thevictim's private key after a small number of key exchange attempts.When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, thesubgroup membership check Y^q ≡ 1 (mod p) is performed using the peer'sown q parameter, not the local key's q. The peer's domain parameters arethen matched against the domain parameters of the private key, but the valueof q is not compared.A malicious peer who presents an X9.42 key carrying the victim's p, g,a forged q = r (a small prime factor of the cofactor), and a publicvalue Y of order r passes all checks. The shared secret then takes onlyr distinct values, leaking priv mod r. Repeating for each small-primefactor of the cofactor and combining via CRT recovers the full privatekey (Lim-Lee / small-subgroup-confinement attack).The realistic attack surface is narrow: principally CMP deployments withlong-lived RA/CA DHX keys and bespoke enterprise or government applicationsusing X9.42 DHX static keys with interactive protocols and therefore thisissue was assigned Low severity.The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are affected by thisissue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0565, the update_snapshot() function in src/terminal.c copies the visible terminal screen into the scrollback buffer when a snapshot is taken. For each screen cell it walks the cell's chars[] array with no upper bound, stopping only when it encounters a NUL terminator. When a cell legitimately fills all VTERM_MAX_CHARS_PER_CELL (6) slots - a base character plus five combining marks - the bundled libvterm returns the array without a terminating NUL, so the loop reads past the fixed six-element array and appends the out-of-bounds values to a buffer reserved for only six characters. A program whose output is rendered inside a :terminal window can trigger this with a short byte sequence and no Vim scripting, leading to a crash. This issue has been patched in version 9.2.0565.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0398-150500.20.49.1).
-
Description: CR/LF bytes were not rejected by HTTP client proxy tunnel headers or host.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_GetBuffer, XML_Parse, XML_ParseBuffer, XML_ParserFree, or XML_ParserReset from within handlers in cases of a policy violation. Thus, a use-after-free can occur,
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.12.1).
-
Description: libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_ResumeParser from within handlers in cases of a policy violation. Thus, a use-after-free can occur (similar to the CVE-2026-50219 situation).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.12.1).
-
Description: libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: A weakness has been identified in svaarala duktape up to 2.99.99. This issue affects some unknown processing of the file duk_api_bytecode.c. Executing a manipulation of the argument count_instr can lead to memory corruption. The attack requires local access. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libduktape206 > 0-0 (version in image is 2.6.0-150500.4.5.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: avoid OGM aggregation when skb tailroom is insufficientWhen OGM aggregation state is toggled at runtime, an existing forwardedpacket may have been allocated with only packet_len bytes, while a laterpacket can still be selected for aggregation. Appending in this case canhit skb_put overflow conditions.Reject aggregation when the target skb tailroom cannot accommodate the newpacket. The caller then falls back to creating a new forward packetinstead of appending.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0530-150500.20.52.1 (version in image is 9.2.0398-150500.20.49.1).
-
Description: In Paramiko through 4.0.0 before a448945, rsakey.py allows the SHA-1 algorithm.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-paramiko > 0-0 (version in image is 3.5.1-150700.20.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix re-decryption of RESPONSE packetsIf a RESPONSE packet gets a temporary failure during processing, it may endup in a partially decrypted state - and then get requeued for a retry.Fix this by just discarding the packet; we will send another CHALLENGEpacket and thereby elicit a further response. Similarly, discard anincoming CHALLENGE packet if we get an error whilst generating a RESPONSE;the server will send another CHALLENGE.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_policy: fix strict mode inbound policy matchingmatch_policy_in() walks sec_path entries from the last transform to thefirst one, but strict policy matching needs to consume info->pol[] inthe same forward order as the rule layout.Derive the strict-match policy position from the number of transformsalready consumed so that multi-element inbound rules are matchedconsistently.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_syncroc_abort_sync() can deadlock with roc_work(). roc_work() holdsdev->mt76.mutex, while cancel_work_sync() waits for roc_work()to finish. If the caller already owns the same mutex, bothsides block and no progress is possible.This deadlock can occur during station removal whenmt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() ->mt7921_roc_abort_sync() invokes cancel_work_sync() whileroc_work() is still running and holding dev->mt76.mutex.This avoids the mutex deadlock and preserves exactly-oncework ownership.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()l3mdev_master_dev_rcu() can return NULL when the slave device is beingun-slaved from a VRF. All other callers deal with this, but we lostthe fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu()with commit 4832c30d5458 ("net: ipv6: put host and anycast routes ondevice with address"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437)I was tempted to rework the un-slaving code to clear the flag firstand insert synchronize_rcu() before we remove the upper. But looks likethe explicit fallback to loopback_dev is an established pattern.And I guess avoiding the synchronize_rcu() is nice, too.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: usb: etas_es58x: correctly anchor the urb in the read bulk callbackWhen submitting an urb, that is using the anchor pattern, it needs to beanchored before submitting it otherwise it could be leaked ifusb_kill_anchored_urbs() is called. This logic is correctly doneelsewhere in the driver, except in the read bulk callback so do thathere also.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boostingRunning stress-ng --schedpolicy 0 on an RT kernel on a big machinemight lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ...The problem is that when a SCHED_DEADLINE task (lock holder) ischanged to a lower priority class via sched_setscheduler(), it mayfail to properly inherit the parameters of potential DEADLINE donorsif it didn't already inherit them in the past (shorter deadline thandonor's at that time). This might lead to bandwidth accountingcorruption, as enqueue_task_dl() won't recognize the lock holder asboosted.The scenario occurs when:1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline)2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happenFix the issue by introducing __setscheduler_dl_pi(), which detects whena DEADLINE (proper or boosted) task gets setscheduled to a lowerpriority class. In case, the function makes the task inherit DEADLINEparameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag toensure proper bandwidth accounting during the next enqueue operation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nf_tables: nft_dynset: fix possible stateful expression memleak in error pathIf cloning the second stateful expression in the element via GFP_ATOMICfails, then the first stateful expression remains in place without beingreleased. unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse()The logicvc_drm_config_parse() function calls of_get_child_by_name() tofind the "layers" node but fails to release the reference, leading to adevice node reference leak.Fix this by using the __free(device_node) cleanup attribute to automaticrelease the reference when the variable goes out of scope.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix race condition during IPSec ESN updateIn IPSec full offload mode, the device reports an ESN (ExtendedSequence Number) wrap event to the driver. The driver validates thisevent by querying the IPSec ASO and checking that the esn_event_armfield is 0x0, which indicates an event has occurred. After handlingthe event, the driver must re-arm the context by setting esn_event_armback to 0x1.A race condition exists in this handling path. After validating theevent, the driver calls mlx5_accel_esp_modify_xfrm() to update thekernel's xfrm state. This function temporarily releases andre-acquires the xfrm state lock.So, need to acknowledge the event first by setting esn_event_arm to0x1. This prevents the driver from reprocessing the same ESN update ifthe hardware sends events for other reason. Since the next ESN updateonly occurs after nearly 2^31 packets are received, there's no risk ofmissing an update, as it will happen long after this handling hasfinished.Processing the event twice causes the ESN high-order bits (esn_msb) tobe incremented incorrectly. The driver then programs the hardware withthis invalid ESN state, which leads to anti-replay failures and acomplete halt of IPSec traffic.Fix this by re-arming the ESN event immediately after it is validated,before calling mlx5_accel_esp_modify_xfrm(). This ensures that anyspurious, duplicate events are correctly ignored, closing the racewindow.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: runtime: Fix a race condition related to device removalThe following code in pm_runtime_work() may dereference the dev->parentpointer after the parent device has been freed: /* Maybe the parent is now able to suspend. */ if (parent && !parent->power.ignore_children) { spin_unlock(&dev->power.lock); spin_lock(&parent->power.lock); rpm_idle(parent, RPM_ASYNC); spin_unlock(&parent->power.lock); spin_lock(&dev->power.lock); }Fix this by inserting a flush_work() call in pm_runtime_remove().Without this patch blktest block/001 triggers the following complaintsporadically:BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081Workqueue: pm pm_runtime_workCall Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Open-code GGTT MMIO access protectionGGTT MMIO access is currently protected by hotplug (drm_dev_enter),which works correctly when the driver loads successfully and is laterunbound or unloaded. However, if driver load fails, this protection isinsufficient because drm_dev_unplug() is never called.Additionally, devm release functions cannot guarantee that all BOs withGGTT mappings are destroyed before the GGTT MMIO region is removed, assome BOs may be freed asynchronously by worker threads.To address this, introduce an open-coded flag, protected by the GGTTlock, that guards GGTT MMIO access. The flag is cleared during thedev_fini_ggtt devm release function to ensure MMIO access is disabledonce teardown begins.(cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: Avoid boot crash in RedBoot partition table parserGiven CONFIG_FORTIFY_SOURCE=y and a recent compiler,commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() whenavailable") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONEAs Kees said, "'names' is pointing to the final 'namelen' many bytesof the allocation ... 'namelen' could be basically any length at all.This fortify warning looks legit to me -- this code used to be readingbeyond the end of the allocation."Since the size of the dynamic allocation is calculated with strlen()we can use strcmp() instead of memcmp() and remain within bounds.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fix statistics allocationThe controller per-cpu statistics is not allocated until after thecontroller has been registered with driver core, which leaves a windowwhere accessing the sysfs attributes can trigger a NULL-pointerdereference.Fix this by moving the statistics allocation to controller allocationwhile tying its lifetime to that of the controller (rather than usingimplicit devres).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: util-linux is a random collection of Linux utilities. Prior to version 2.41.4, a TOCTOU (Time-of-Check-Time-of-Use) vulnerability has been identified in the SUID binary /usr/bin/mount from util-linux. The mount binary, when setting up loop devices, validates the source file path with user privileges via fork() + setuid() + realpath(), but subsequently re-canonicalizes and opens it with root privileges (euid=0) without verifying that the path has not been replaced between both operations. Neither O_NOFOLLOW, nor inode comparison, nor post-open fstat() are employed. This allows a local unprivileged user to replace the source file with a symlink pointing to any root-owned file or device during the race window, causing the SUID binary to open and mount it as root. Exploitation requires an /etc/fstab entry with user,loop options whose path points to a directory where the attacker has write permission, and that /usr/bin/mount has the SUID bit set (the default configuration on virtually all Linux distributions). The impact is unauthorized read access to root-protected files and block devices, including backup images, disk volumes, and any file containing a valid filesystem. This issue has been patched in version 2.41.4.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libblkid1 < 2.40.4-150700.4.13.1 (version in image is 2.40.4-150700.4.10.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm/bus: Fix potential use after free in asynchronous initializationDingisoul with KASAN reports a use after free if device_add() fails innd_async_device_register().Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent whilescheduling async init") correctly added a reference on the parent deviceto be held until asynchronous initialization was complete. However, ifdevice_add() results in an allocation failure the ref count of thedevice drops to 0 prior to the parent pointer being accessed. Thusresulting in use after free.The bug bot AI correctly identified the fix. Save a reference to theparent pointer to be used to drop the parent reference regardless of theoutcome of device_add().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Defer sub-object cleanup in export put callbackssvc_export_put() calls path_put() and auth_domain_put() immediatelywhen the last reference drops, before the RCU grace period. RCUreaders in e_show() and c_show() access both ex_path (viaseq_path/d_path) and ex_client->name (via seq_escape) withoutholding a reference. If cache_clean removes the entry and drops thelast reference concurrently, the sub-objects are freed while stillin use, producing a NULL pointer dereference in d_path.Commit 2530766492ec ("nfsd: fix UAF when access ex_uuid orex_stats") moved kfree of ex_uuid and ex_stats into thecall_rcu callback, but left path_put() and auth_domain_put() runningbefore the grace period because both may sleep and call_rcucallbacks execute in softirq context.Replace call_rcu/kfree_rcu with queue_rcu_work(), which defers thecallback until after the RCU grace period and executes it in processcontext where sleeping is permitted. This allows path_put() andauth_domain_put() to be moved into the deferred callback alongsidethe other resource releases. Apply the same fix to expkey_put(),which has the identical pattern with ek_path and ek_client.A dedicated workqueue scopes the shutdown drain to only NFSDexport release work items; flushing the sharedsystem_unbound_wq would stall on unrelated work from othersubsystems. nfsd_export_shutdown() uses rcu_barrier() followedby flush_workqueue() to ensure all deferred release callbackscomplete before the export caches are destroyed.Reviwed-by: Jeff Layton
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free in update_super_work when racing with umountCommit b98535d09179 ("ext4: fix bug_on in start_this_handle during umountfilesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_workto prevent new error work from being queued via /proc/fs/ext4/xx/mb_groupsreads during unmount. However, this introduced a use-after-free becauseupdate_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() whichaccesses the kobject's kernfs_node after it has been freed by kobject_del()in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work)Instead of reordering the teardown sequence, fix this by makingext4_notify_error_sysfs() detect that sysfs has already been torn downby checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() callin that case. A dedicated mutex (s_error_notify_mutex) serializesext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()to prevent TOCTOU races where the kobject could be deleted between thestate_in_sysfs check and the sysfs_notify() call.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix potential deadlock in cpu hotplug with osnoiseThe following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK]Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/syscalls: Add spectre boundary for syscall dispatch tableThe s390 syscall number is directly controlled by userspace, but doesnot have an array_index_nospec() boundary to prevent access past thesyscall function pointer tables.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:esp: fix skb leak with espintcp and async cryptoWhen the TX queue for espintcp is full, esp_output_tail_tcp willreturn an error and not free the skb, because with synchronous crypto,the common xfrm output code will drop the packet for us.With async crypto (esp_output_done), we need to drop the skb whenesp_output_tail_tcp returns an error.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: bcm: bcm2835-power: Increase ASB control timeoutThe bcm2835_asb_control() function uses a tight polling loop to waitfor the ASB bridge to acknowledge a request. During intensive workloads,this handshake intermittently fails for V3D's master ASB on BCM2711,resulting in "Failed to disable ASB master for v3d" errors duringruntime PM suspend. As a consequence, the failed power-off leaves V3D ina broken state, leading to bus faults or system hangs on later accesses.As the timeout is insufficient in some scenarios, increase the pollingtimeout from 1us to 5us, which is still negligible in the context of apower domain transition. Also, replace the open-coded ktime_get_ns()/cpu_relax() polling loop with readl_poll_timeout_atomic().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Clear stale exiting pointer in futex_lock_pi() retry pathFuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSYand stores a refcounted task pointer in 'exiting'.After wait_for_owner_exiting() consumes that reference, the local pointeris never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns adifferent error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting)Fix this by resetting upon retry, essentially aligning it with requeue_pi.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: amdisp: Fix resume-probe race condition issueIdentified resume-probe race condition in kernel v7.0 with the commit38fa29b01a6a ("i2c: designware: Combine the init functions"),but thisissue existed from the beginning though not detected.The amdisp i2c device requires ISP to be in power-on state for probeto succeed. To meet this requirement, this device is added to genpdto control ISP power using runtime PM. The pm_runtime_get_sync() calledbefore i2c_dw_probe() triggers PM resume, which powers on ISP and alsoinvokes the amdisp i2c runtime resume before the probe completes resultingin this race condition and a NULL dereferencing issue in v7.0Fix this race condition by using the genpd APIs directly during probe: - Call dev_pm_genpd_resume() to Power ON ISP before probe - Call dev_pm_genpd_suspend() to Power OFF ISP after probe - Set the device to suspended state with pm_runtime_set_suspended() - Enable runtime PM only after the device is fully initialized
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanupDisable the delayed work before clearing BAR mappings and doorbells toavoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU: Fix FPDSS on Zen1Zen1's hardware divider can leave, under certain circumstances, partialresults from previous operations. Those results can be leaked byanother, attacker thread.Fix that with a chicken bit.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix reference count leak in rxrpc_server_keyring()This patch fixes a reference count leak in rxrpc_server_keyring()by checking if rx->securities is already set.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()When dma_map_single() fails in tse_start_xmit(), the function returnsNETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells thestack the packet was consumed, the skb is never freed, leaking memoryon every DMA mapping failure.Add dev_kfree_skb_any() before returning to properly free the skb.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: flowlabel: defer exclusive option free until RCU teardown`ip6fl_seq_show()` walks the global flowlabel hash under the seq-fileRCU read-side lock and prints `fl->opt->opt_nflen` when an option blockis present.Exclusive flowlabels currently free `fl->opt` as soon as `fl->users`drops to zero in `fl_release()`. However, the surrounding`struct ip6_flowlabel` remains visible in the global hash table untillater garbage collection removes it and `fl_free_rcu()` finally tears itdown.A concurrent `/proc/net/ip6_flowlabel` reader can therefore race thatearly `kfree()` and dereference freed option state, triggering a crashin `ip6fl_seq_show()`.Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matchesthe lifetime already required for the enclosing flowlabel while readerscan still reach it under RCU.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()Ignore -EBUSY when checking nested events after exiting a blocking statewhile L2 is active, as exiting to userspace will generate a spurioususerspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM'sdemise. Continuing with the wakeup isn't perfect either, as *something*has gone sideways if a vCPU is awakened in L2 with an injected event (orworse, a nested run pending), but continuing on gives the VM a decentchance of surviving without any major side effects.As explained in the Fixes commits, it _should_ be impossible for a vCPU tobe put into a blocking state with an already-injected event (exception,IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injectedevents, and thus put the vCPU into what should be an impossible state.Don't bother trying to preserve the WARN, e.g. with an anti-syzkallerKconfig, as WARNs can (hopefully) be added in paths where _KVM_ would beviolating x86 architecture, e.g. by WARNing if KVM attempts to inject anexception or interrupt while the vCPU isn't running.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/crypto: chacha: Zeroize permuted_state before it leaves scopeSince the ChaCha permutation is invertible, the local variable'permuted_state' is sufficient to compute the original 'state', and thusthe key, even after the permutation has been done.While the kernel is quite inconsistent about zeroizing secrets on thestack (and some prominent userspace crypto libraries don't bother at allsince it's not guaranteed to work anyway), the kernel does try to do itas a best practice, especially in cases involving the RNG.Thus, explicitly zeroize 'permuted_state' before it goes out of scope.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel/uncore: Fix die ID init and look up bugsIn snbep_pci2phy_map_init(), in the nr_node_ids > 8 path,uncore_device_to_die() may return -1 when all CPUs associatedwith the UBOX device are offline.Remove the WARN_ON_ONCE(die_id == -1) check for two reasons:- The current code breaks out of the loop. This is incorrect because pci_get_device() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.- Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error.Separately, when NUMA is disabled on a NUMA-capable platform,pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die()to return -1 for all PCI devices. As a result,spr_update_device_location(), used on Intel SPR and EMR, ignores thecorresponding PMON units and does not add them to the RB tree.Fix this by using uncore_pcibus_to_dieid(), which retrieves topologyfrom the UBOX GIDNIDMAP register and works regardless of whether NUMAis enabled in Linux. This requires snbep_pci2phy_map_init() to beadded in spr_uncore_pci_init().Keep uncore_device_to_die() only for the nr_node_ids > 8 case, whereNUMA is expected to be enabled.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Fix race in DMA ring dequeueThe HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked formultiple transfers that timeout around the same time. However, thefunction is not serialized and can race with itself.When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processesincomplete transfers, and then restarts the ring. If another timeouttriggers a parallel call into the same function, the two instances mayinterfere with each other - stopping or restarting the ring at unexpectedtimes.Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect toitself.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix double free issue for tx spare bufferIn hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structureis created for rollback. However, the tx_spare pointer in the originalring handle is incorrectly left pointing to the old backup memory.Later, if memory allocation fails in hns3_init_all_ring() during the setup,the error path attempts to free all newly allocated rings. Since tx_sparecontains a stale (non-NULL) pointer from the backup, it is mistaken fora newly allocated buffer and is erroneously freed, leading to a double-freeof the backup memory.The root cause is that the tx_spare field was not cleared after its valuewas saved in tmp_rings, leaving a dangling pointer.Fix this by setting tx_spare to NULL in the original ring structurewhen the creation of the new `tx_spare` fails. This ensures theerror cleanup path only frees genuinely newly allocated buffers.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/rt: Skip currently executing CPU in rto_next_cpu()CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-boundRT task, and a CFS task stuck in kernel space. When other CPUs switch fromRT to non-RT tasks, RT load balancing (LB) is triggered; withHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the executionof rto_push_irq_work_func. During push_rt_task on CPU0,if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHEDand after the push operation completes, CPU0 calls rto_next_cpu().Since only CPU0 is overloaded in this scenario, rto_next_cpu() shouldideally return -1 (no further IPI needed).However, multiple CPUs invoking tell_cpu_to_push() during LB incrementsrd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch betweenrd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart itssearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory&& rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work toitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded andother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,which triggers a CPU hardlockup due to continuous self-interrupts.The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_onrto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next)rd->rto_loop != next rto_next_cpu irq_work_queue_onrto_push_irq_work_funcFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().This solution has been verified to effectively eliminate spurious self-IPIsand prevent CPU hardlockup scenarios.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocationI have been observing a number of systems aborting atinsert_dev_extents() in btrfs_create_pending_block_groups(). Thefollowing is a sample stack trace of such an abort coming from forcedchunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but thiscan theoretically happen to any DUP chunk allocation. [81.801] ------------[ cut here ]------------ [81.801] BTRFS: Transaction aborted (error -17) [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319 [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs] [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282 [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000 [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0 [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007 [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000 [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000 [81.809] FS: 00007fec6bdd9740(0000) GS:ffff8e6b1b379000(0000) knlGS:0000000000000000 [81.809] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81.810] CR2: 00005604833670f0 CR3: 0000000116679000 CR4: 00000000000006f0 [81.810] Call Trace: [81.810] [81.810] __btrfs_end_transaction+0x3e/0x2b0 [btrfs] [81.811] btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs] [81.811] kernfs_fop_write_iter+0x15f/0x240 [81.812] vfs_write+0x264/0x500 [81.812] ksys_write+0x6c/0xe0 [81.812] do_syscall_64+0x66/0x770 [81.812] entry_SYSCALL_64_after_hwframe+0x76/0x7e [81.813] RIP: 0033:0x7fec6be66197 [81.814] RSP: 002b:00007fffb159dd30 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [81.815] RAX: ffffffffffffffda RBX: 00007fec6bdd9740 RCX: 00007fec6be66197 [81.815] RDX: 0000000000000002 RSI: 0000560483374f80 RDI: 0000000000000001 [81.816] RBP: 0000560483374f80 R08: 0000000000000000 R09: 0000000000000000 [81.816] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002 [81.817] R13: 00007fec6bfb85c0 R14: 00007fec6bfb5ee0 R15: 00005604833729c0 [81.817] [81.817] irq event stamp: 20039 [81.818] hardirqs last enabled at (20047): [] __up_console_sem+0x52/0x60 [81.818] hardirqs last disabled at (20056): [] __up_console_sem+0x37/0x60 [81.819] softirqs last enabled at (19470): [] __irq_exit_rcu+0x96/0xc0 [81.819] softirqs last disabled at (19463): [] __irq_exit_rcu+0x96/0xc0 [81.820] ---[ end trace 0000000000000000 ]--- [81.820] BTRFS: error (device dm-7 state A) in btrfs_create_pending_block_groups:2876: errno=-17 Object already existsInspecting these aborts with drgn, I observed a pattern of overlappingchunk_maps. Note how stripe 1 of the first chunk overlaps in physicaladdress with stripe 0 of the second chunk.Physical Start Physical End Length Logical Type Stripe----------------------------------------------------------------------------------------------------0x0000000102500000 0x0000000142500000 1.0G 0x0000000641d00000 META|DUP 0/20x0000000142500000 0x0000000182500000 1.0G 0x0000000641d00000 META|DUP 1/20x0000000142500000 0x0000000182500000 1.0G 0x0000000601d00000 META|DUP 0/20x0000000182500000 0x00000001c2500000 1.0G 0x0000000601d00000 META|DUP 1/2Now how could this possibly happen? All chunk allocation is---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix inline data read failure for ztailpacking pclustersCompressed folios for ztailpacking pclusters must be valid before addingthese pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster()may assume they are already valid and then trigger a NULL pointerdereference.It is somewhat hard to reproduce because the inline data is in the sameblock as the tail of the compressed indexes, which are usually read justbefore. However, it may still happen if a fatal signal arrives whileread_mapping_folio() is running, as shown below: erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : z_erofs_decompress_queue+0x4c8/0xa14 lr : z_erofs_decompress_queue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_read+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0Fix this by reading the inline data before allocating and addingthe pclusters to the I/O chains.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Clear Present bit before tearing down context entryWhen tearing down a context entry, the current implementation zeros theentire 128-bit entry using multiple 64-bit writes. This creates a windowwhere the hardware can fetch a "torn" entry - where some fields arealready zeroed while the 'Present' bit is still set - leading tounpredictable behavior or spurious faults.While x86 provides strong write ordering, the compiler may reorder writesto the two 64-bit halves of the context entry. Even without compilerreordering, the hardware fetch is not guaranteed to be atomic withrespect to multiple CPU writes.Align with 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 context entry first to signal the transition of ownership from hardware to software.2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.4. Fully zero out the entry only after the invalidation is complete.Also, add a dma_wmb() to context_set_present() to ensure the entryis fully initialized before the 'Present' bit becomes visible.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix UMR hang in LAG error state unloadDuring firmware reset in LAG mode, a race condition causes the driverto hang indefinitely while waiting for UMR completion during deviceunload. See [1].In LAG mode the bond device is only registered on the master, so itnever sees sys_error events from the slave.During firmware reset this causes UMR waits to hang forever on unloadas the slave is dead but the master hasn't entered error state yet, soUMR posts succeed but completions never arrive.Fix this by adding a sys_error notifier that gets registered beforeMLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device().This ensures error events reach the bond device throughout teardown.[1]Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib] ? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core] ? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs] uverbs_destroy_uobject+0x37/0x150 [ib_uverbs] __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs] uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] remove_client_context+0x8b/0xd0 [ib_core] disable_device+0x8c/0x130 [ib_core] __ib_unregister_device+0x10d/0x180 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib] auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core] mlx5_disable_lag+0x253/0x260 [mlx5_core] mlx5_lag_disable_change+0x89/0xc0 [mlx5_core] mlx5_eswitch_disable+0x67/0xa0 [mlx5_core] mlx5_unload+0x15/0xd0 [mlx5_core] mlx5_unload_one+0x71/0xc0 [mlx5_core] mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core] process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/shstk: Prevent deadlock during shstk sigreturnDuring sigreturn the shadow stack signal frame is popped. The kernel doesthis by reading the shadow stack using normal read accesses. When it can'tassume the memory is shadow stack, it takes extra steps to makes sure it isreading actual shadow stack memory and not other normal readable memory. Itdoes this by holding the mmap read lock while doing the access and checkingthe flags of the VMA.Unfortunately that is not safe. If the read of the shadow stack sigframehits a page fault, the fault handler will try to recursively grab anothermmap read lock. This normally works ok, but if a writer on another CPU isalso waiting, the second read lock could fail and cause a deadlock.Fix this by not holding mmap lock during the read access to userspace.Instead use mmap_lock_speculate_...() to watch for changes between droppingmmap lock and the userspace access. Retry if anything grabbed an mmap writelock in between and could have changed the VMA.These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is onlyavailable when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACKdepend on it. On x86, PER_VMA_LOCK is a default configuration for SMPkernels. So drop support for the other configs under the assumption thatthe !SMP shadow stack user base does not exist.Currently there is a check that skips the lookup work when the SSP can beassumed to be on a shadow stack. While reorganizing the function, removethe optimization to make the tricky code flows more common, such thatissues like this cannot escape detection for so long.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Prevent NULL deref when RX memory exhaustedThe CPU receives frames from the MAC through conventional DMA: the CPUallocates buffers for the MAC, then the MAC fills them and returnsownership to the CPU. For each hardware RX queue, the CPU and MACcoordinate through a shared ring array of DMA descriptors: onedescriptor per DMA buffer. Each descriptor includes the buffer'sphysical address and a status flag ("OWN") indicating which side ownsthe buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to setthe flag and the MAC is only allowed to clear it, and both must movethrough the ring in sequence: thus the ring is used for both"submissions" and "completions."In the stmmac driver, stmmac_rx() bookmarks its position in the ringwith the `cur_rx` index. The main receive loop in that function checksfor rx_descs[cur_rx].own=0, gives the corresponding buffer to thenetwork stack (NULLing the pointer), and increments `cur_rx` modulo thering size. After the loop exits, stmmac_rx_refill(), which bookmarks itsposition with `dirty_rx`, allocates fresh buffers and rearms thedescriptors (setting OWN=1). If it fails any allocation, it simply stopsearly (leaving OWN=0) and will retry where it left off when next called.This means descriptors have a three-stage lifecycle (terms my own):- `empty` (OWN=1, buffer valid)- `full` (OWN=0, buffer valid and populated)- `dirty` (OWN=0, buffer NULL)But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. Inthe past (see 'Fixes:'), there was a bug where the loop could cycle`cur_rx` all the way back to the first descriptor it dirtied, resultingin a NULL dereference when mistaken for `full`. The aforementionedcommit resolved that *specific* failure by capping the loop's iterationlimit at `dma_rx_size - 1`, but this is only a partial fix: if theprevious stmmac_rx_refill() didn't complete, then there are leftover`dirty` descriptors that the loop might encounter without needing tocycle fully around. The current code therefore panics (see 'Closes:')when stmmac_rx_refill() is memory-starved long enough for `cur_rx` tocatch up to `dirty_rx`.Fix this by explicitly checking, before advancing `cur_rx`, if the nextentry is dirty; exit the loop if so. This prevents processing of thefinal, used descriptor until stmmac_rx_refill() succeeds, butfully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfixintended: so remove the clamp as well. Since stmmac_rx_zc() is acopy-paste-and-tweak of stmmac_rx() and the code structure is identical,any fix to stmmac_rx() will also need a corresponding fix forstmmac_rx_zc(). Therefore, apply the same check there.In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after theMAC sets OWN=0 on the final descriptor, it will be unable to send anyfurther DMA-complete IRQs until it's given more `empty` descriptors.Currently, the driver simply *hopes* that the next stmmac_rx_refill()succeeds, risking an indefinite stall of the receive process if not. Butthis is not a regression, so it can be addressed in a future change.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()Two bugs exist in the vCPU initialisation path:1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup path jumps to 'unlock' without calling unpin_host_vcpu() or unpin_host_sve_state(), permanently leaking pin references on the host vCPU and SVE state pages. Extract a register_hyp_vcpu() helper that performs the checks and the store. When register_hyp_vcpu() returns an error, call unpin_host_vcpu() and unpin_host_sve_state() inline before falling through to the existing 'unlock' label.2. register_hyp_vcpu() publishes the new vCPU pointer into 'hyp_vm->vcpus[]' with a bare store, allowing a concurrent caller of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU object. Ensure the store uses smp_store_release() and the load uses smp_load_acquire(). While 'vm_table_lock' currently serialises the store and the load, these barriers ensure the reader sees the fully initialised 'hyp_vcpu' object even if there were a lockless path or if the lock's own ordering guarantees were insufficient for nested object initialization.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: ADD_ADDR rtx: free sk if lastWhen an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(),and released at the end.If at that moment, it was the last reference being held, the sk wouldnot be freed. sock_put() should then be called instead of __sock_put().But that's not enough: if it is the last reference, sock_put() will callsk_free(), which will end up calling sk_stop_timer_sync() on the sametimer, and waiting indefinitely to finish. So it is needed to mark thatthe timer is done at the end of the timer handler when it has not beenrescheduled, not to call sk_stop_timer_sync() on "itself".
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix accept queue count leak on transport mismatchvirtio_transport_recv_listen() calls sk_acceptq_added() beforevsock_assign_transport(). If vsock_assign_transport() fails orselects a different transport, the error path returns withoutcalling sk_acceptq_removed(), permanently incrementingsk_ack_backlog.After approximately backlog+1 such failures, sk_acceptq_is_full()returns true, causing the listener to reject all new connections.Fix by moving sk_acceptq_added() to after the transport validation,matching the pattern used by vmci_transport and hyperv_transport.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_freenvmet_tcp_release_queue_work() runs on nvmet-wq and can drop thefinal controller reference through nvmet_cq_put(). If that triggersnvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work onthe same nvmet-wq.Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- nvmet_add_async_event queue_work(nvmet_wq, &ctrl->async_event_work);This trips lockdep with a possible recursive locking warning.[ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55[ 5223.061801] loop0: detected capacity change from 0 to 2097152[ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1[ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420)[ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.[ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349[ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"[ 5233.227718] ============================================[ 5233.231283] WARNING: possible recursive locking detected[ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N[ 5233.238434] --------------------------------------------[ 5233.241852] kworker/u192:6/2413 is trying to acquire lock:[ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90[ 5233.251438] but task is already holding lock:[ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0[ 5233.261125] other info that might help us debug this:[ 5233.265333] Possible unsafe locking scenario:[ 5233.269217] CPU0[ 5233.270795] ----[ 5233.272436] lock((wq_completion)nvmet-wq);[ 5233.275241] lock((wq_completion)nvmet-wq);[ 5233.278020] *** DEADLOCK ***[ 5233.281793] May be due to missing lock nesting notation[ 5233.286195] 3 locks held by kworker/u192:6/2413:[ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0[ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0[ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530[ 5233.304290] stack backtrace:[ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full)[ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST[ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp][ 5233.306532] Call Trace:[ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0[ 5233.306552] print_deadlock_bug+0x225/0x2f0[ 5233.306556] __lock_acquire+0x13f0/0x2290[ 5233.306563] lock_acquire+0xd0/0x300[ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90[ 5233.306571] ? __flush_work+0x20b/0x530[ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90[ 5233.306577] touch_wq_lockdep_map+0x3b/0x90[ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90[ 52---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix unlocked test for dm_suspended_mdThe function dm_blk_report_zones tests if the device is suspended withthe "dm_suspended_md" call. However, this function is called withoutholding any locks, so the device may be suspended just after it.Move the call to dm_suspended_md after dm_get_live_table, so that thedevice can't be suspended after the suspended state was tested.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_queue: hold bridge skb->dev while queuedbr_pass_frame_up() rewrites skb->dev from the ingress port to the bridgemaster before queueing bridge LOCAL_IN packets. NFQUEUE only holdsreferences on state.in/out and bridge physdevs, so a queued bridgepacket can retain a freed bridge master in skb->dev until reinjection.When the verdict is reinjected later, br_netif_receive_skb() re-entersthe receive path with skb->dev still pointing at the freed bridge master,triggering a use-after-free.Store skb->dev in the queue entry, hold a reference on it for the queuelifetime, and use the saved device when dropping queued packets duringNETDEV_DOWN handling.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_hbh: reject oversized option listsstruct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors,but hbh_mt6_check() does not reject larger optsnr values supplied fromuserspace.Validate optsnr in the rule setup path so only match data that fits thefixed-size opts array can be installed. This follows the existing xtablespattern of rejecting invalid user-provided counts in checkentry() andkeeps the packet matching path unchanged.`struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array,where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible:[ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29[ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]'
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: fix inode reference leak in fsnotify_recalc_mask()fsnotify_recalc_mask() fails to handle the return value of__fsnotify_recalc_mask(), which may return an inode pointer that needsto be released via fsnotify_drop_object() when the connector's HAS_IREFflag transitions from set to cleared.This manifests as a hung task with the following call trace: INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotify_sb_delete generic_shutdown_super kill_anon_super cleanup_mnt task_work_run do_exit do_group_exitThe race window that triggers the iref leak: Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotify_add_mark_locked(): fsnotify_add_mark_list(): spin_lock(conn->lock) add mark_B(evictable) to list spin_unlock(conn->lock) return /* ---- gap: no lock held ---- */ fsnotify_detach_mark(mark_A): spin_lock(mark_A->lock) clear ATTACHED flag on mark_A spin_unlock(mark_A->lock) fsnotify_put_mark(mark_A) fsnotify_recalc_mask(): spin_lock(conn->lock) __fsnotify_recalc_mask(): /* mark_A skipped: ATTACHED cleared */ /* only mark_B(evictable) remains */ want_iref = false has_iref = true /* not yet cleared */ -> HAS_IREF transitions true -> false -> returns inode pointer spin_unlock(conn->lock) /* BUG: return value discarded! * iput() and fsnotify_put_sb_watched_objects() * are never called */Fix this by deferring the transition true -> false of HAS_IREF flag fromfsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix af_unix null-ptr-deref in proto updateunix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state,TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe thatsocket is properly set up, which would include having a defined peer. IOW,there's a window when unix_stream_bpf_update_proto() can be called onsocket which still has unix_peer(sk) == NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)sock_map_sk_state_allowed(sk)...sk_pair = unix_peer(sk)sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newskBUG: kernel NULL pointer dereference, address: 0000000000000080RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInitial idea was to move peer assignment _before_ the sk_state update[1],but that involved an additional memory barrier, and changing the hot pathwas rejected.Then a NULL check during proto update in unix_stream_bpf_update_proto() wasconsidered[2], but the follow-up discussion[3] focused on the root cause,i.e. sockmap update taking a wrong lock. Or, more specifically, missingunix_state_lock()[4].In the end it was concluded that teaching sockmap about the af_unix lockingwould be unnecessarily complex[5].Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACTare allowed to update sockmaps, sock_map_update_elem() taking the unixlock, as it is currently implemented in unix_state_lock():spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() takenin a process context, followed by a softirq-context TC BPF programattempting to take the same spinlock -- deadlock[6].This way we circled back to the peer check idea[2].[1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/[2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/[3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/[5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/[6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/Summary of scenarios where af_unix/stream connect() may race a sockmapupdate:1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf.2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s: Fix unmap race with PMD migration entriesThe following race is possible with migration swap entries ordevice-private THP entries. e.g. when move_pages is called on a PMD THPpage, then there maybe an intermediate state, where PMD entry acts asa migration swap entry (pmd_present() is true). Then if an munmaphappens at the same time, then this VM_BUG_ON() can happen inpmdp_huge_get_and_clear_full().This patch fixes that.Thread A: move_pages() syscall add_folio_for_migration() mmap_read_lock(mm) folio_isolate_lru(folio) mmap_read_unlock(mm) do_move_pages_to_node() migrate_pages() try_to_migrate_one() spin_lock(ptl) set_pmd_migration_entry() pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn set_pmd_at() # PMD: migration swap entry (pmd_present=0) spin_unlock(ptl) [page copy phase] # <--- RACE WINDOW -->Thread B: munmap() mmap_write_downgrade(mm) unmap_vmas() -> zap_pmd_range() zap_huge_pmd() __pmd_trans_huge_lock() pmd_is_huge(): # !pmd_present && !pmd_none -> TRUE (swap entry) pmd_lock() -> # spin_lock(ptl), waits for Thread A to release ptl pmdp_huge_get_and_clear_full() VM_BUG_ON(!pmd_present(*pmdp)) # HITS![ 287.738700][ T1867] ------------[ cut here ]------------[ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187!cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0] pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c lr: c000000000645dec: zap_huge_pmd+0xb0/0x868 sp: c00000044037f790 msr: 800000000282b033 current = 0xc0000004032c1a00 paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09 pid = 1867, comm = a.outkernel BUG at :187!Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026enter ? for help[link register ] c000000000645dec zap_huge_pmd+0xb0/0x868[c00000044037f790] c00000044037f7d0 (unreliable)[c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868[c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40[c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8[c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128[c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310[c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238[c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8[c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40[c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350[c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec---- Exception: 3000 (System Call Vectored) at 0000000010064a2cSP (7fff9b1ee9c0) is in userspace0:mon> zhcommit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"),enabled migration for device-private PMD entries. Hence this is oneother path where this warning could get trigger from. ------------[ cut here ]------------ WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905 Modules linked in: test_hmm CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 Call Trace: [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable) [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c000000604707760] [c00000000063e5a4] migrate_vma_col---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock between reflink and transaction commit when using flushoncommitWhen using the flushoncommit mount option, we can have a deadlock betweena transaction commit and a reflink operation that copied an inline extentto an offset beyond the current i_size of the destination node.The deadlock happens like this:1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page();2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc;3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero);4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED). So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A.Syzbot recently reported this with the following stack traces: INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid:---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoisonTwo concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page cantrigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lockwhen racing with a concurrent unmap: thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK!The out: path in __get_huge_page_for_hwpoison() calls folio_put() to dropthe GUP reference while the hugetlb_lock is still held by the hugetlb.cwrapper get_huge_page_for_hwpoison(). If concurrent unmap has releasedthe page table mapping reference, folio_put() drops the folio refcount tozero, triggering free_huge_folio() which attempts to re-acquire thenon-recursive hugetlb_lock.Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapperinto get_huge_page_for_hwpoison(). Place spin_unlock_irq() before thefolio_put() at the out: label so the folio is always released outside thelock.[akpm@linux-foundation.org: fix race, rename label per Miaohe]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: synproxy: add mutex to guard hook reference countingAs the synproxy infrastructure register netfilter hooks on-demand when auser adds the first iptables target or nftables expression, if doneconcurrently they can race each other.Introduce a mutex to serialize the refcount control blocks access fromboth frontends. While a per namespace mutex might be more efficient, itis not needed for target/expression like SYNPROXY.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: bz2.BZ2Decompressor objects could be reused after a decompression error. If an application caught the resulting OSError and retried with the same decompressor, crafted input could cause the decompressor to resume from an invalid internal state and perform out-of-bounds writes to a stack buffer. This could crash the process when processing untrusted data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: validate USB endpointsThe pegasus driver should validate that the device it is probing has theproper number and types of USB endpoints it is expecting before it bindsto it. If a malicious device were to not have the same urbs the driverwill crash later on when it blindly accesses these endpoints.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ucan: Fix infinite loop from zero-length messagesIf a broken ucan device gets a message with the message length field setto 0, then the driver will loop for forever inucan_read_bulk_callback(), hanging the system. If the length is 0, justskip the message and go on to the next one.This has been fixed in the kvaser_usb driver in the past in commit0c73772cd2b8 ("can: kvaser_usb: leaf: Fix potential infinite loop incommand parsers"), so there must be some broken devices out there likethis somewhere.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: kaweth: validate USB endpointsThe kaweth driver should validate that the device it is probing has theproper number and types of USB endpoints it is expecting before it bindsto it. If a malicious device were to not have the same urbs the driverwill crash later on when it blindly accesses these endpoints.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()A malicious USB device claiming to be a CDC Phonet modem can overflowthe skb_shared_info->frags[] array by sending an unbounded sequence offull-page bulk transfers.Drop the skb and increment the length error when the frag limit isreached. This matches the same fix that commit f0813bcd2d9d ("net:wwan: t7xx: fix potential skb->frags overflow in RX path") did for thet7xx driver.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: A flaw was found in github.com/go-viper/mapstructure/v2, in the field processing component using mapstructure.WeakDecode. This vulnerability allows information disclosure through detailed error messages that may leak sensitive input values via malformed user-supplied data processed in security-critical contexts.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdpprocess_sdp() declares union nf_inet_addr rtp_addr on the stack andpasses it to the nf_nat_sip sdp_session hook after walking the SDPmedia descriptions. However rtp_addr is only initialized inside themedia loop when a recognized media type with a non-zero port is found.If the SDP body contains no m= lines, only inactive media sections(m=audio 0 ...) or only unrecognized media types, rtp_addr is neverassigned. Despite that, the function still calls hooks->sdp_session()with &rtp_addr, causing nf_nat_sdp_session() to format the stale stackvalue as an IP address and rewrite the SDP session owner and connectionlines with it.With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) thisresults in the session-level o= and c= addresses being rewritten to0.0.0.0 for inactive SDP sessions. Without stack auto-init therewritten address is whatever happened to be on the stack.Fix this by pre-initializing rtp_addr from the session-level connectionaddress (caddr) when available, and tracking via a have_rtp_addr flagwhether any valid address was established. Skip the sdp_session hookentirely when no valid address exists.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: read UNIX_DIAG_VFS data under unix_state_lockExact UNIX diag lookups hold a reference to the socket, but not tou->path. Meanwhile, unix_release_sock() clears u->path underunix_state_lock() and drops the path reference after unlocking.Read the inode and device numbers for UNIX_DIAG_VFS while holdingunix_state_lock(), then emit the netlink attribute after dropping thelock.This keeps the VFS data stable while the reply is being built.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()The ethtool tsconfig Netlink path can trigger a null pointerdereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower()results in generic_hwtstamp_ioctl_lower() being called withkernel_cfg->ifr as NULL.The generic_hwtstamp_ioctl_lower() function does not expecta NULL ifr and dereferences it, leading to a system crash.Fix this by adding a NULL check for kernel_cfg->ifr ingeneric_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Avoid creating sub-groups asynchronouslyThe asynchronous creation of sub-groups by a delayed work could lead to aNULL pointer dereference when the driver directory is removed before thework completes.The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0Fix this issue by using configfs_add_default_group() API which does nothave the deadlock problem as configfs_register_group() and does not requirethe delayed work handler.[mani: slightly reworded the description and added stable list]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leakIn gs_can_open(), the URBs for USB-in transfers are allocated, added to theparent->rx_submitted anchor and submitted. In the complete callbackgs_usb_receive_bulk_callback(), the URB is processed and resubmitted. Ings_can_close() the URBs are freed by callingusb_kill_anchored_urbs(parent->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 gs_can_close().Fix the memory leak by anchoring the URB in thegs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfnetlink_osf: validate individual option lengths in fingerprintsnfnl_osf_add_callback() validates opt_num bounds and stringNUL-termination but does not check individual option length fields.A zero-length option causes nf_osf_match_one() to enter the optionmatching loop even when foptsize sums to zero, which matches packetswith no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573)Additionally, an MSS option (kind=2) with length < 4 causesout-of-bounds reads when nf_osf_match_one() unconditionally accessesoptp[2] and optp[3] for MSS value extraction. While RFC 9293section 3.2 specifies that the MSS option is always exactly 4bytes (Kind=2, Length=4), the check uses "< 4" rather than"!= 4" because lengths greater than 4 do not cause memorysafety issues -- the buffer is guaranteed to be at leastfoptsize bytes by the ctx->optsize == foptsize check.Reject fingerprints where any option has zero length, or where an MSSoption has length less than 4, at add time rather than trusting thesevalues in the packet matching hot path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: add missing netlink policy validationsHyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.These attributes are used by the kernel without any validation.Extend the netlink policies accordingly.Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid overflows in ip6_datagram_send_ctl()Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`:- In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). ----truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()A malicious or compromised VIO server can return a num_written value in thediscover targets MAD response that exceeds max_targets. This value isstored directly in vhost->num_targets without validation, and is then usedas the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], whichis only allocated for max_targets entries. Indices at or beyond max_targetsaccess kernel memory outside the DMA-coherent allocation. Theout-of-bounds data is subsequently embedded in Implicit Logout and PLOGIMADs that are sent back to the VIO server, leaking kernel memory.Fix by clamping num_written to max_targets before storing it.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: use the current queue number for statsThere's a potential mismatch between the memory reserved for statisticsand the amount of memory written.gem_get_sset_count() correctly computes the number of stats based on theactive queues, whereas gem_get_ethtool_stats() indiscriminately copiesdata using the maximum number of queues, and in the case the number ofactive queues is less than MACB_MAX_QUEUES, this results in a OOB writeas observed in the KASAN splat.==================================================================BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb]Write of size 760 at addr ffff80008080b000 by task ethtool/1027CPU: [...]Tainted: [E]=UNSIGNED_MODULEHardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0The buggy address belongs to the physical page:page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff)raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================Fix it by making sure the copied size only considers the active number ofqueues.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_key: validate families in pfkey_send_migrate()syzbot was able to trigger a crash in skb_put() [1]Issue is that pfkey_send_migrate() does not check old/new families,and that set_ipsecrequest() @family argument was truncated,thus possibly overfilling the skb.Validate families early, do not wait set_ipsecrequest().[1]skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 !Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:seg6: separate dst_cache for input and output paths in seg6 lwtunnelThe seg6 lwtunnel uses a single dst_cache per encap route, sharedbetween seg6_input_core() and seg6_output_core(). These two pathscan perform the post-encap SID lookup in different routing contexts(e.g., ip rules matching on the ingress interface, or VRF tableseparation). Whichever path runs first populates the cache, and theother reuses it blindly, bypassing its own lookup.Fix this by splitting the cache into cache_input and cache_output,so each path maintains its own cached dst independently.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_multiport: validate range encoding in checkentryports_match_v1() treats any non-zero pflags entry as the start of aport range and unconditionally consumes the next ports[] element asthe range end.The checkentry path currently validates protocol, flags and count, butit does not validate the range encoding itself. As a result, malformedrules can mark the last slot as a range start or place two range startsback to back, leaving ports_match_v1() to step past the last validports[] element while interpreting the rule.Reject malformed multiport v1 rules in checkentry by validating thateach range start has a following element and that the following elementis not itself marked as another range start.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/mc: Fix error path ordering in edac_mc_alloc()When the mci->pvt_info allocation in edac_mc_alloc() fails, the error pathwill call put_device() which will end up calling the device's releasefunction.However, the init ordering is wrong such that device_initialize() happens*after* the failed allocation and thus the device itself and the releasefunction pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ...Reorder the calling sequence so that the device is initialized and thus therelease function pointer is properly set before it can be used.This was found by Claude while reviewing another EDAC patch.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reserve enough transaction items for qgroup ioctlsCurrently our qgroup ioctls don't reserve any space, they just do atransaction join, which does not reserve any space, neither for the quotatree updates nor for the delayed refs generated when updating the quotatree. The quota root uses the global block reserve, which is fine most ofthe time since we don't expect a lot of updates to the quota root, or tobe too close to -ENOSPC such that other critical metadata updates need toresort to the global reserve.However this is not optimal, as not reserving proper space may result in atransaction abort due to not reserving space for delayed refs and thenabusing the use of the global block reserve.For example, the following reproducer (which is unlikely to model anyreal world use case, but just to illustrate the problem), triggers such atransaction abort due to -ENOSPC when running delayed refs: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs quota enable $MNT for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done umount $MNTWhen running this, we can see in dmesg/syslog that a transaction aborthappened: [436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 num_bytes 16384 type 176 action 1 ref_mod 1: -28 [436.493] ------------[ cut here ]------------ [436.494] BTRFS: Transaction aborted (error -28) [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs], CPU#4: umount/2495372 [436.497] Modules linked in: btrfs loop (...) [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [436.510] Tainted: [W]=WARN [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [436.513] RIP: 0010:btrfs_run_delayed_refs+0xdf/0x110 [btrfs] [436.514] Code: 0f 82 ea (...) [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292 [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001 [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80 [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867 [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400 [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000 [436.526] FS: 00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000 [436.527] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0 [436.530] Call Trace: [436.530] [436.530] btrfs_commit_transaction+0x73/0xc00 [btrfs] [436.531] ? btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs] [436.532] sync_filesystem+0x7a/0x90 [436.533] generic_shutdown_super+0x28/0x180 [436.533] kill_anon_super+0x12/0x40 [436.534] btrfs_kill_super+0x12/0x20 [btrfs] [436.534] deactivate_locked_super+0x2f/0xb0 [436.534] cleanup_mnt+0xea/0x180 [436.535] task_work_run+0x58/0xa0 [436.535] exit_to_user_mode_loop+0xed/0x480 [436.536] ? __x64_sys_umount+0x68/0x80 [436.536] do_syscall_64+0x2a5/0xf20 [436.537] entry_SYSCALL_64_after_hwframe+0x76/0x7e [436.537] RIP: 0033:0x7fe5906b6217 [436.538] Code: 0d 00 f7 (...) [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217 [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100 [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff [436.544] R10: 0000000000000103 R11: ---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0435, an OS command injection vulnerability exists in Vim's :find command-line completion. When the path option contains backtick-enclosed shell commands, those commands are executed during file name completion. Because the path option lacks the P_SECURE flag, it can be set from a modeline, allowing an attacker who controls the contents of a file to execute arbitrary shell commands when the user opens that file in Vim and triggers :find completion. This issue has been patched in version 9.2.0435.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0530-150500.20.52.1 (version in image is 9.2.0398-150500.20.49.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ebtables: fix OOB read in compat_mtw_from_userLuxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets.AFAIU this is relevant for matches that need to go thoughmatch->compat_from_user() call. Those that use plain memcpy with theuser-provided size are ok because the caller checks that size vs thestart of the next rule entry offset (which itself is checked vs. totalsize copied from userspace).The ->compat_from_user() callbacks assume they can read compatsize bytes,so they need this extra check.Based on an earlier patch from Luxiao Xu.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: fix IPv6 route referencing IPv4 nexthopsyzbot reported a panic [1] [2].When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flagof all groups containing this nexthop is not updated. This is becausenh_group_v4_update is only called when replacing AF_INET to AF_INET6,but the reverse direction (AF_INET6 to AF_INET) is missed.This allows a stale has_v4=false to bypass fib6_check_nexthop, causingIPv6 routes to be attached to groups that effectively contain only AF_INETmembers. Subsequent route lookups then call nexthop_fib6_nh() whichreturns NULL for the AF_INET member, leading to a NULL pointerdereference.Fix by calling nh_group_v4_update whenever the family changes, not justAF_INET to AF_INET6.Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1[1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0[2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate group add input before caching[BUG]OCFS2_IOC_GROUP_ADD can trigger a BUG_ON inocfs2_set_new_buffer_uptodate():kernel BUG at fs/ocfs2/uptodate.c:509!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509Code: ffffe88f 42b9fe4c 89e64889 dfe8b4dfCall Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 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/0x7eRIP: 0033:0x7bbfb55a966d[CAUSE]ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on auser-controlled group block before ocfs2_verify_group_and_input()validates that block number. That helper is only valid for newlyallocated metadata and asserts that the block is not already present inthe chosen metadata cache. The code also uses INODE_CACHE(inode) eventhough the group descriptor belongs to main_bm_inode and later journalaccesses use that cache context instead.[FIX]Validate the on-disk group descriptor before caching it, then add it tothe metadata cache tracked by INODE_CACHE(main_bm_inode). Keep thevalidation failure path separate from the later cleanup path so we onlyremove the buffer from that cache after it has actually been inserted.This keeps the group buffer lifetime consistent across validation,journaling, and cleanup.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.
Packages affected:
- sle-module-desktop-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.37.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: add bounds check for if_id in IRQ handlerThe IRQ handler extracts if_id from the upper 16 bits of the hardwarestatus register and uses it to index into ethsw->ports[] withoutvalidation. Since if_id can be any 16-bit value (0-65535) but the portsarray is only allocated with sw_attr.num_ifs elements, this can lead toan out-of-bounds read potentially.Add a bounds check before accessing the array, consistent with theexisting validation in dpaa2_switch_rx().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zeroThe driver allocates arrays for ports, FDBs, and filter blocks usingkcalloc() with ethsw->sw_attr.num_ifs as the element count. When thedevice reports zero interfaces (either due to hardware configurationor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)instead of NULL.Later in dpaa2_switch_probe(), the NAPI initialization unconditionallyaccesses ethsw->ports[0]->netdev, which attempts to dereferenceZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.Add a check to ensure num_ifs is greater than zero after retrievingdevice attributes. This prevents the zero-sized allocations andsubsequent invalid pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: go-git is a highly extensible git implementation library written in pure Go. Prior to 5.16.5, a vulnerability was discovered in go-git whereby data integrity values for .pack and .idx files were not properly verified. This resulted in go-git potentially consuming corrupted files, which would likely result in unexpected errors such as object not found. For context, clients fetch packfiles from upstream Git servers. Those files contain a checksum of their contents, so that clients can perform integrity checks before consuming it. The pack indexes (.idx) are generated locally by go-git, or the git cli, when new .pack files are received and processed. The integrity checks for both files were not being verified correctly. This vulnerability is fixed in 5.16.5.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- amazon-ssm-agent < 3.3.4624.0-150000.5.37.1 (version in image is 3.3.1611.0-150000.5.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before accessl2cap_information_rsp() checks that cmd_len covers the fixedl2cap_info_rsp header (type + result, 4 bytes) but then readsrsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers anout-of-bounds read of adjacent skb data.Guard each data access with the required payload length check. If thepayload is too short, skip the read and let the state machine completewith safe defaults (feat_mask and remote_fixed_chan remain zero fromkzalloc), so the info timer cleanup and l2cap_conn_start() still runand the connection is not stalled.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: br_nd_send: linearize skb before parsing ND optionsbr_nd_send() parses neighbour discovery options from ns->opt[] andassumes that these options are in the linear part of request.Its callers only guarantee that the ICMPv6 header and target addressare available, so the option area can still be non-linear. Parsingns->opt[] in that case can access data past the linear buffer.Linearize request before option parsing and derive ns from the linearnetwork header.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rnbd-srv: Zero the rsp buffer before using itBefore using the data buffer to send back the response message, zero itcompletely. This prevents any stray bytes to be picked up by the clientside when there the message is exchanged between different protocolversions.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSEFSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparseattribute and saves it through xattr without any permission checks.This exposes two issues:1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not.2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here.Add both share-level writable check and per-handle access check.Use goto out on error to avoid leaking file references.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh < 9.6p1-150600.6.42.1 (version in image is 9.6p1-150600.6.37.1).
-
Description: Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable toBleichenbacher-style attack when an attacker is able to provide the CMS orS/MIME messages and observe the error code and/or decryption output.Impact summary: The Bleichenbacher-style attack allows an attacker to use thevictim's vulnerable application as a way to decrypt or sign messages with thevictim's private RSA key.The attack is possible in 2 variants.1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used withoutproviding the recipient certificate. In this case OpenSSL iterates over everyKeyTransRecipientInfo (KTRI) without stopping at the first success.An attacker who authors a message with two KTRI entries - the first onewrapping a real CEK under the victim's public key, the second with anarbitrary probe ciphertext - obtains opportunity to iterate the 2nd KTRI toget a valid PKCS#1 v1.5 padding if the error code of the application isavailable.That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): anadaptive-chosen-ciphertext side channel from which the attacker decrypts anyRSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature underit.2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided withthe recipient certificate, and the recipient is not found, a randomkey is substituted.An attacker who authors a message and is able to compare both error code andthe result of the decryption, can mount a Bleichenbacher oracle.We are not aware of any applications that provide a remote attackeran opportunity to mount an attack described in these scenarios. We considerthe existence of such application very unlikely, and for this reason thisCVE has been evaluated as Low severity.To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, theinvoked EVP_PKEY_decrypt() will use the implicit rejection mechanism describedin draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicitrejection was explicitly disabled.The implicit rejection mechanism always returns a plaintext value,the symmetric key. This result is deterministic for the ciphertext and theprivate key. The length of the decryption result can happen to match thelength of the key of the symmetric cipher that was used for the contentencryption. When a certificate is not provided, the last RecipientInfoproducing a key that looks valid will be used. It may cause getting garbagecontent on decryption. As a proper way to deal with this a recipientcertificate has to be provided to identify the particular RecipientInfo fordecryption.The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, asCMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handlingThe `tpg->tpg_nexus` pointer in the USB Target driver is dynamicallymanaged and tied to userspace configuration via ConfigFS. It can beNULL if the USB host sends requests before the nexus is fullyestablished or immediately after it is dropped.Currently, functions like `bot_submit_command()` and the datatransfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediatelydereference `tv_nexus->tvn_se_sess` without any validation. If amalicious or misconfigured USB host sends a BOT (Bulk-Only Transport)command during this race window, it triggers a NULL pointerdereference, leading to a kernel panic (local DoS).This exposes an inconsistent API usage within the module, as peerfunctions like `usbg_submit_command()` and `bot_send_bad_response()`correctly implement a NULL check for `tv_nexus` before proceeding.Fix this by bringing consistency to the nexus handling. Add themissing `if (!tv_nexus)` checks to the vulnerable BOT command andrequest processing paths, aborting the command gracefully with anerror instead of crashing the system.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fix use-after-free on controller registration failureMake sure to deregister from driver core also in the unlikely event thatper-cpu statistics allocation fails during controller registration toavoid use-after-free (of driver resources) and unclocked registeraccesses.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]To create and manage guests, domctl operations are used by the controldomain, a possible Xenstore domain, or by a domain controlling aparticular guest. Some of these operations may not be executed inparallel, so a system-wide lock is used. The way that lock is acquiredis, however, not providing any fairness. This is CVE-2026-42489.Furthermore, with XSM/Flask in use, the lock acquire will, for someoperations, occur ahead of any permission checking. This isCVE-2026-42490.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- xen-libs < 4.20.3_06-150700.3.41.1 (version in image is 4.20.3_04-150700.3.36.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix iloc.bh leak in ext4_fc_replay_inode() error pathsDuring code review, Joseph found that ext4_fc_replay_inode() callsext4_get_fc_inode_loc() to get the inode location, which holds areference to iloc.bh that must be released via brelse().However, several error paths jump to the 'out' label withoutreleasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failureFix this by introducing an 'out_brelse' label placed just beforethe existing 'out' label to ensure iloc.bh is always released.Additionally, make ext4_fc_replay_inode() propagate errorsproperly instead of always returning 0.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventfs: Hold eventfs_mutex and SRCU when remount walks eventsCommit 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from theevents descriptor") had eventfs_set_attrs() recurse through ei->childrenon remount. The walk only holds the rcu_read_lock() taken bytracefs_apply_options() over tracefs_inodes, which is wrong: - list_for_each_entry over ei->children races with the list_del_rcu() in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as d2603279c7d6. - eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...). rcu_read_lock() does not extend an SRCU grace period, so ti->private can be reclaimed under the walk. - The writes to ei->attr race with eventfs_set_attr(), which holds eventfs_mutex.Reproducer: while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done & while :; do echo "p:kp submit_bio" > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events doneWrap the events portion of tracefs_apply_options() ineventfs_remount_lock()/_unlock() that take eventfs_mutex andsrcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so thenested rcu_read_lock() is fine; lockdep_assert_held() pins the contract.Comment in tracefs_drop_inode() said "RCU cycle" -- it is SRCU.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mctp i2c: initialise event handler read bytesSet a 0xff value for i2c reads of an mctp-i2c device. Otherwise readswill return "val" from the i2c bus driver. For i2c-aspeed andi2c-npcm7xx that is a stack uninitialised u8.Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2cinstance, now it returns all 0xff.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: libusb before version 1.0.30 contains a one-byte out-of-bounds read vulnerability in parse_iad_array() in descriptor.c that allows attackers to trigger a denial of service by supplying a malformed USB descriptor whose bLength equals size minus one, causing the bounds check to use the original buffer size instead of the remaining size. Attackers in virtualized environments with USB passthrough can supply crafted descriptors through libusb_get_active_interface_association_descriptors or libusb_get_interface_association_descriptors to read one byte past the end of the malloc allocation, resulting in a denial of service.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libusb-1_0-0 > 0-0 (version in image is 1.0.24-150400.3.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: fix strparser anchor skb leak on offload RX setup failureWhen tls_set_device_offload_rx() fails at tls_dev_add(), the error pathcalls tls_sw_free_resources_rx() to clean up the SW context that wasinitialized by tls_set_sw_offload(). This function callstls_sw_release_resources_rx() (which stops the strparser viatls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context),but never frees the anchor skb that was allocated by alloc_skb(0) intls_strp_init().Note that tls_sw_free_resources_rx() is exclusively used for this"failed to start offload" code path, there's no other caller.The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not usethe standard strparser"), because the standard strparser doesn't tryto pre-allocate an skb.The normal close path in tls_sk_proto_close() handles cleanup by callingtls_sw_strparser_done() (which calls tls_strp_done()) after droppingthe socket lock, because tls_strp_done() does cancel_work_sync() andthe strparser work handler takes the socket lock.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: always drain queued discard work in ext4_mb_release()While reviewing recent ext4 patch[1], Sashiko raised the followingconcern[2]:> If the filesystem is initially mounted with the discard option,> deleting files will populate sbi->s_discard_list and queue> s_discard_work. If it is then remounted with nodiscard, the> EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is> neither cancelled nor flushed.[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.devThe concern was valid, but it had nothing to do with the patch[1].One of the problems with Sashiko in its current (early) form is thatit will detect pre-existing issues and report it as a problem with thepatch that it is reviewing.In practice, it would be hard to hit deliberately (unless you are amalicious syzkaller fuzzer), since it would involve mounting the filesystem with -o discard, and then deleting a large number of files,remounting the file system with -o nodiscard, and then immediatelyunmounting the file system before the queued discard work has a changeto drain on its own.Fix it because it's a real bug, and to avoid Sashiko from raising thisconcern when analyzing future patches to mballoc.c.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: http.cookies.Morsel.js_output() returns an inline inside the generated script element. Mitigation base64-encodes the cookie value to disallow escaping using cookie value.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: Issue summary: Parsing a crafted DER-encoded ASN.1 structure with a primitiveelement whose content exceeds 2 gigabytes in length may cause a heap bufferover-read on 64-bit Unix and Unix-like platforms.Impact summary: The heap buffer over-read may crash the application (Denial ofService) or to load into the decoded ASN.1 object contents of memory beyond theend of the input buffer. More typically such ASN.1 elements would instead betruncated.An integer truncation in OpenSSL's ASN.1 decoder causes the content length ofan ASN.1 primitive element to be mishandled when it exceeds 2 gigabytes. In theworst case the truncated length is treated as a request to scan the binarycontent for a terminating zero byte, possibly causing OpenSSL to read eitherless than or beyond the end of the allocated buffer.Applications that pass attacker-supplied data to d2i_X509(), d2i_PKCS7(), orany other d2i_* decoding function are affected. OpenSSL's own command-linetools are not vulnerable, as data read through the BIO layer is checked beforeit reaches the affected code. The issue only affects 64-bit Unix and Unix-likeplatforms; 32-bit platforms and 64-bit Windows are not affected.The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by this issue,as the affected code is outside the OpenSSL FIPS module boundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl1_1 < 1.1.1w-150700.11.22.1 (version in image is 1.1.1w-150700.11.19.1).
-
Description: Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap)processes attacker-supplied CMS data, an attacker-chosen stream-mode KEKcipher can trigger a heap out-of-bounds read in kek_unwrap_key().Impact summary: A heap buffer over-read may trigger a crash which leads toDenial of Service for an application if the input buffer ends at a memorypage boundary and the following page is unmapped. There is no informationdisclosure as the over-read bytes are not revealed to the attacker.The key unwrapping function performs a check-byte test as specified in theRFC that reads 7 bytes from a heap allocation that is based on the wrappedkey length from the message. There is a minimum length check based on theblock length of the wrapping cipher. However the cipher is selected froman OID carried in the attacker's PWRI keyEncryptionAlgorithm with norequirement that the cipher be a block cipher. When an attacker selectsa stream-mode cipher the guard will be ineffective and the allocated buffercontaining the unwrapped key can be too small to fit the check-bytesspecified in the RFC and a buffer over-read can happen.Applications calling CMS_decrypt() or CMS_decrypt_set1_password()(equivalently openssl cms -decrypt -pwri_password ...) on untrusted CMSdata are vulnerable to this issue. No password knowledge is required: theover-read happens during the unwrap attempt before any authenticationsucceeds.The over-read is limited to a few bytes and is not written to output, sothere is no information disclosure. Triggering a crash requires theallocation to border unmapped memory, which is unlikely with the normalallocator.The FIPS modules are not affected by this issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl1_1 < 1.1.1w-150700.11.22.1 (version in image is 1.1.1w-150700.11.19.1).
-
Description: PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).
-
Description: A vulnerability exists where a connection requiring TLS incorrectly reuses anexisting unencrypted connection from the same connection pool. If an initialtransfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent requestto that same host bypasses the TLS requirement and instead transmit dataunencrypted.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
Description: libcurl might in some circumstances reuse the wrong connection for SMB(S)transfers.libcurl features a pool of recent connections so that subsequent requests canreuse an existing connection to avoid overhead.When reusing a connection a range of criteria must be met. Due to a logicalerror in the code, a network transfer operation that was requested by anapplication could wrongfully reuse an existing SMB connection to the sameserver that was using a different 'share' than the new subsequent transfershould.This could in unlucky situations lead to the download of the wrong file or theupload of a file to the wrong place. When this happens, the same credentialsare used and the server name is the same.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
Description: Using libcurl, when a custom `Host:` header is first set for an HTTP requestand a second request is subsequently done using the same *easy handle* butwithout the custom `Host:` header set, the second request would use staleinformation and pass on cookies meant for the first host in the secondrequest. Leak them.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.14.1).
-
Description: In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.
Packages affected:
- sle-module-desktop-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.37.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: in-kernel: always mark signal+subflow endp as usedSyzkaller managed to find a combination of actions that was generatingthis warning: msk->pm.local_addr_used == 0 WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline] RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline] RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 ___sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: 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 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 The actions that caused that seem to be: - Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADD_ADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: pip handles concatenated tar and ZIP files as ZIP files regardless of filename or whether a file is both a tar and ZIP file. This behavior could result in confusing installation behavior, such as installing "incorrect" files according to the filename of the archive. New behavior only proceeds with installation if the file identifies uniquely as a ZIP or tar archive, not as both.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).
-
Description: bzip2 contains an off-by-one error in the bzip2recover utility. When processing a specially crafted file, the application performs an out-of-bounds write to a global buffer, resulting in memory corruption and a crash (denial of service).This issue was fixed in bzip2 patch 35d122a3df8b0cc4082a4d89fdc6ee99f375fe67
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libbz2-1 > 0-0 (version in image is 1.0.8-150400.1.122).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: af_key: zero aligned sockaddr tail in PF_KEY exportsPF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddrpayload space, so IPv6 addresses occupy 32 bytes on the wire. However,`pfkey_sockaddr_fill()` initializes only the first 28 bytes of`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.Not every PF_KEY message is affected. The state and policy dump buildersalready zero the whole message buffer before filling the sockaddrpayloads. Keep the fix to the export paths that still append alignedsockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE`Fix those paths by clearing only the aligned sockaddr tail after`pfkey_sockaddr_fill()`.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing a manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be used for attacks.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing a manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be used for attacks. This patch is called 16357. It is best practice to apply a patch to resolve this issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error pathsWhen processing mount options, efivarfs allocates efivarfs_fs_info (sfi)early in fs_context initialization. However, sfi is associated with thesuperblock and typically freed when the superblock is destroyed. If thefs_context is released (final put) before fill_super is called-such ason error paths or during reconfiguration-the sfi structure would leak,as ownership never transfers to the superblock.Implement the .free callback in efivarfs_context_ops to ensure anyallocated sfi is properly freed if the fs_context is torn down beforefill_super, preventing this memory leak.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug information. A logic error in the handling of DWARF compilation units can result in an invalid offset_size value being used inside byte_get_little_endian, leading to an abort (SIGABRT). The issue was observed in binutils 2.44. A local attacker can trigger the crash by supplying a malicious input file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: GNU Binutils thru 2.46 readelf contains a null pointer dereference vulnerability when processing a crafted ELF binary with malformed header fields. During relocation processing, an invalid or null section pointer may be passed into display_relocations(), resulting in a segmentation fault (SIGSEGV) and abrupt termination. No evidence of memory corruption beyond the null pointer dereference, nor any possibility of code execution, was observed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: GNU Binutils thru 2.46 readelf contains a vulnerability that leads to an abort (SIGABRT) when processing a crafted ELF binary with malformed DWARF abbrev or debug information. Due to incomplete state cleanup in process_debug_info(), an invalid debug_info_p state may propagate into DWARF attribute parsing routines. When certain malformed attributes result in an unexpected data length of zero, byte_get_little_endian() triggers a fatal abort. No evidence of memory corruption or code execution was observed; the impact is limited to denial of service.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: maple: free entry on mas_store_gfp() failureregcache_maple_write() allocates a new block ('entry') to mergeadjacent ranges and then stores it with mas_store_gfp().When mas_store_gfp() fails, the new 'entry' remains allocated andis never freed, leaking memory.Free 'entry' on the failure path; on success continue freeing thereplaced neighbor blocks ('lower', 'upper').
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: release admin tagset if init failsnvme_fabrics creates an NVMe/FC controller in following path: nvmf_dev_write() -> nvmf_create_ctrl() -> nvme_fc_create_ctrl() -> nvme_fc_init_ctrl()nvme_fc_init_ctrl() allocates the admin blk-mq resources right afternvme_add_ctrl() succeeds. If any of the subsequent steps fail (changingthe controller state, scheduling connect work, etc.), we jump to thefail_ctrl path, which tears down the controller references but neverfrees the admin queue/tag set. The leaked blk-mq allocations match thekmemleak report seen during blktests nvme/fc.Check ctrl->ctrl.admin_tagset in the fail_ctrl path and callnvme_remove_admin_tag_set() when it is set so that all admin queueallocations are reclaimed whenever controller setup aborts.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK};rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata().The reserved members of the structure were not zeroed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: atmel-sha204a - Fix OOM ->tfm_count leakIf memory allocation fails, decrement ->tfm_count to avoid blockingfuture reads.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: account for netlink header sizeThis is a followup to an old bug fix: NLMSG_DONE needs to accountfor the netlink header size, not just the attribute size.This can result in a WARN splat + drop of the netlink message,but other than this there are no ill effects.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_expect: skip expectations in other netns via procSkip expectations that do not reside in this netns.Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns'sconntrack entries via proc").
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan966x: fix page pool leak in error pathslan966x_fdma_rx_alloc() creates a page pool but does not destroy it ifthe subsequent fdma_alloc_coherent() call fails, leaking the pool.Similarly, lan966x_fdma_init() frees the coherent DMA memory whenlan966x_fdma_tx_alloc() fails but does not destroy the page pool thatwas successfully created by lan966x_fdma_rx_alloc(), leaking it.Add the missing page_pool_destroy() calls in both error paths.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm_user: fix info leak in build_report()struct xfrm_user_report is a __u8 proto field followed by a structxfrm_selector which means there is three "empty" bytes of padding, butthe padding is never zeroed before copying to userspace. Fix that up byzeroing the structure before setting individual member variables.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- runc > 0-0 (version in image is 1.3.4-150000.94.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix memory leaks in ceph_mdsc_build_path()Add __putname() calls to error code paths that did not free the "path"pointer obtained by __getname(). If ownership of this pointer is notpassed to the caller via path_info.path, the function must free itbefore returning.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix memory leak in pqi_report_phys_luns()pqi_report_phys_luns() fails to release the rpl_list buffer whenencountering an unsupported data format or when the allocation forrpl_16byte_wwid_list fails. These early returns bypass the cleanup logic,leading to memory leaks.Consolidate the error handling by adding an out_free_rpl_list label and usegoto statements to ensure rpl_list is consistently freed on failure.Compile tested only. Issue found using a prototype static analysis tool andcode review.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handlerThe UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) functionallocates memory for the device path using kobject_get_path(). If thelength of the device path exceeds the output buffer length, the functionreturns -ENOSPC but does not free the allocated memory, resulting in amemory leak.Add a kfree() call to the error path to ensure the allocated memory isproperly freed.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: fix memory leaks in gfs2_fill_super error pathFix two memory leaks in the gfs2_fill_super() error handling path whentransitioning a filesystem to read-write mode fails.First leak: kthread objects (thread_struct, task_struct, etc.)When gfs2_freeze_lock_shared() fails after init_threads() succeeds, thecreated kernel threads (logd and quotad) are never destroyed. Thisoccurs because the fail_per_node label doesn't callgfs2_destroy_threads().Second leak: quota bitmap buffer (8192 bytes)When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds butbefore other operations complete, the allocated quota bitmap is neverfreed.The fix moves thread cleanup to the fail_per_node label to handle allerror paths uniformly. gfs2_destroy_threads() is safe to callunconditionally as it checks for NULL pointers. Quota cleanup is addedin gfs2_make_fs_rw() to properly handle the withdrawal case wherequota initialization succeeds but the filesystem is then withdrawn.Thread leak backtrace (gfs2_freeze_lock_shared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copy_process+0x3a1/0x4670 kernel/fork.c:2422 kernel_clone+0xf3/0x6e0 kernel/fork.c:2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c:478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265Quota leak backtrace (gfs2_make_fs_rw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctxThe bounce buffers are allocated with __get_free_pages() usingBOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation errorpath and nx842_crypto_free_ctx() release the buffers with free_page().Use free_pages() with the matching order instead.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: igorplugusb: heed coherency rulesIn a control request, the USB request structurecan be subject to DMA on some HCs. Hence it must obeythe rules for DMA coherency. Allocate it separately.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix empty payload in tap skb for non-linear buffersFor non-linear skbs, virtio_transport_build_skb() goes throughvirtio_transport_copy_nonlinear_skb() to copy the original payloadin the new skb to be delivered to the vsockmon tap device.This manually initializes an iov_iter but does not set iov_iter.count.Since the iov_iter is zero-initialized, the copy length is zero and nopayload is actually copied to the monitor interface, leaving dataun-initialized.Fix this by removing the linear vs non-linear split and usingskb_copy_datagram_iter() with iov_iter_kvec() for all cases, asvhost-vsock already does. This handles both linear and non-linear skbs,properly initializes the iov_iter, and removes the now unusedvirtio_transport_copy_nonlinear_skb().While touching this code, let's also check the return value ofskb_copy_datagram_iter(), even though it's unlikely to fail.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tap: free page on error paths in tap_get_user_xdp()tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,and returns -ENOMEM when build_skb() fails. Both paths jump to the errlabel without freeing the page that vhost_net_build_xdp() allocated forthe frame. tap_sendmsg() discards the per-buffer return value and alwaysreturns 0, so vhost_tx_batch() takes the success path and never freesthe page; each rejected frame in a batch leaks one page-frag chunk.Free the page on both error paths, before the skb is built. This is thetap counterpart of the same leak in tun_xdp_one().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: free page on build_skb failure in tun_xdp_one()When build_skb() fails in tun_xdp_one(), the function sets ret to-ENOMEM and jumps to the out label, which returns without freeing thepage that vhost_net_build_xdp() allocated for the frame. As with theshort-frame rejection path, tun_sendmsg() discards the per-buffer errorand still returns total_len, so vhost_tx_batch() takes the success pathand never frees the page. Each build_skb() failure in a batch leaks onepage-frag chunk.Free the page before taking the error path, matching the put_page() theother error exits of tun_xdp_one() already perform.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix a buffer leak in __ceph_setxattr()The old_blob in __ceph_setxattr() can storeci->i_xattrs.prealloc_blob value during the retry.However, it is never called the ceph_buffer_put()for the old_blob object. This patch fixes the issue ofthe buffer leak.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Issue Summary: The PKCS#12 file processing fails to perform sufficient inputvalidation for files that use Password-Based Message Authentication Code 1(PBMAC1) integrity mechanism allowing a certificate and private key forgery.Impact Summary: An attacker impersonating a user can cause a service readingPKCS#12 files to accept forged certificates and private keys with a 1 in 256probability.If a service accepting PKCS#12 files is using passwords for authenticatingthe received files, the attacker can create unencrypted PKCS#12 files thatuse PBMAC1 authentication that specifies an HMAC key of only one byte, allowingthem to craft a file that will be accepted with a 1 in 256 probability.That would then cause the service to accept a certificate and private keycontrolled by the attacker.The FIPS modules are not affected by this issue, as the affected code isoutside the OpenSSL FIPS module boundary.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.36.1 (version in image is 3.2.3-150700.5.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: free skb on nci_transceive early error pathsnci_transceive() takes ownership of the skb passed by the caller,but the -EPROTO, -EINVAL, and -EBUSY error paths return withoutfreeing it.Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changesthe nci/nci_dev selftest hits the error path occasionally in NIPA,and kmemleak detects leaks:unreferenced object 0xff11000015ce6a40 (size 640): comm "nci_dev", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.
Packages affected:
- sle-module-desktop-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.37.1).
-
Description: In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.12.1).
-
Description: CMS (Cryptographic Message Syntax) parsing in gpgsm in GnuPG through 2.5.20 mishandles the CMS format for AES-GCM because aes-ICVlen is supposed to be 12 bytes but 4 bytes is accepted. NOTE: this is related to CVE-2026-34182.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.15.1).
-
Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- net-tools > 0-0 (version in image is 2.0+git20170221.479bb4a-150000.5.13.1).
-
Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: complete pending data exchange on device closeIn nci_close_device(), complete any pending data exchange beforeclosing. The data exchange callback (e.g.rawsock_data_exchange_complete) holds a socket reference.NIPA occasionally hits this leak:unreferenced object 0xff1100000f435000 (size 2048): comm "nci_dev", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/entry: Scrub r12 register on kernel entryBefore commit f33f2d4c7c80 ("s390/bp: remove TIF_ISOLATE_BP"),all entry handlers loaded r12 with the current task pointer(lg %r12,__LC_CURRENT) for use by the BPENTER/BPEXIT macros. Thatcommit removed TIF_ISOLATE_BP, dropping both the branch predictionmacros and the r12 load, but did not add r12 to the register clearingsequence.Add the missing xgr %r12,%r12 to make the register scrub consistentacross all entry points.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh < 9.6p1-150600.6.42.1 (version in image is 9.6p1-150600.6.37.1).
-
Description: libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isofs: validate Rock Ridge CE continuation extent against volume sizerock_continue() reads rs->cont_extent verbatim from the Rock Ridge CErecord and passes it to sb_bread() without checking that the blocknumber is within the mounted ISO 9660 volume. commit e595447e177b("[PATCH] rock.c: handle corrupted directories") added cont_offsetand cont_size rejection for the CE continuation but did not validatethe extent block number itself. commit f54e18f1b831 ("isofs: Fixinfinite looping over CE entries") later capped the CE chain lengthat RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.With a crafted ISO mounted via udisks2 (desktop optical auto-mount)or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point atan out-of-range block or at blocks belonging to an adjacentfilesystem on the same block device. sb_bread() on an out-of-rangeblock returns NULL cleanly via the block layer EIO path, so thereis no memory-safety violation. For in-range reads of adjacent-filesystem data, the CE buffer is parsed as Rock Ridge records andonly the text of SL sub-records reaches userspace throughreadlink(), which makes the info-leak channel narrow and difficultto exploit; still, rejecting the malformed CE outright matches therejection shape already present in the same function forcont_offset and cont_size.Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() nextto the existing offset/size rejection, printing the samecorrupted-directory-entry notice.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: fix missing expect put in obj evalnft_ct_expect_obj_eval() allocates an expectation and may callnf_ct_expect_related(), but never drops its local reference.Add nf_ct_expect_put(exp) before return to balance allocation.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.52.1).
-
Description: Unknown.
Packages affected:
- sle-module-server-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- util-linux > 0-0 (version in image is 2.40.4-150700.4.10.1).
-
Description: Unknown.
Packages affected:
- sle-module-server-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- util-linux > 0-0 (version in image is 2.40.4-150700.4.10.1).
-
Description: Unknown.
Packages affected:
- sle-module-server-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- util-linux > 0-0 (version in image is 2.40.4-150700.4.10.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: fix race condition in qman_destroy_fqWhen QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition betweenfq_table[fq->idx] state and freeing/allocating from the pool andWARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered.Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL;And adding some logs between qman_release_fqid() andfq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more.To prevent that, ensure that fq_table[fq->idx] is set to NULL beforegen_pool_free() is called by using smp_wmb().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0383, an OS command injection vulnerability exists in the netrw standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the sftp:// or file:// protocol handlers), an attacker can execute arbitrary shell commands with the privileges of the Vim process. This issue has been patched in version 9.2.0383.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0530-150500.20.52.1 (version in image is 9.2.0398-150500.20.49.1).
-
Description: xmlwf in libexpat before 2.8.2 has an integer overflow for the output filename when -d outputDir is used.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).
-
Description: xmlwf in libexpat before 2.8.2 has an integer overflow in resolveSystemId.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.15-150600.3.53.1).