-
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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: esp: avoid in-place decrypt on shared skb fragsMSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCPmarks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),so later paths that may modify packet data can first make a privatecopy. The IPv4/IPv6 datagram append paths did not set this flag whensplicing pages into UDP skbs.That leaves an ESP-in-UDP packet made from shared pipe pages lookinglike an ordinary uncloned nonlinear skb. ESP input then takes the no-COWfast path for uncloned skbs without a frag_list and decrypts in placeover data that is not owned privately by the skb.Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matchingTCP. Also make ESP input fall back to skb_cow_data() when the flag ispresent, so ESP does not decrypt externally backed frags in place.Private nonlinear skb frags still use the existing fast path.This intentionally does not change ESP output. In esp_output_head(),the path that appends the ESP trailer to existing skb tailroom withoutcalling skb_cow_data() is not reachable for nonlinear skbs:skb_tailroom() returns zero when skb->data_len is nonzero, while ESPtailen is positive. Thus ESP output will either use the separatedestination-frag path or fall back to skb_cow_data().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: skbuff: propagate shared-frag marker through frag-transfer helpersTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) failto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags whenmoving frags from source to destination. __pskb_copy_fclone() defersthe rest of the shinfo metadata to skb_copy_header() after copyingfrag descriptors, but that helper only carries over gso_{size,segs,type} and never touches skb_shinfo()->flags; skb_shift() moves fragdescriptors directly and leaves flags untouched. As a result, thedestination skb keeps a reference to the same externally-owned orpage-cache-backed pages while reporting skb_has_shared_frag() asfalse.The mismatch is harmful in any in-place writer that usesskb_has_shared_frag() to decide whether shared pages must be detouredthrough skb_cow_data(). ESP input is one such writer (esp4.c,esp6.c), and a single nft 'dup to ' rule -- or any othernf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'dskb in esp_input() with the marker stripped, letting an unprivilegeduser write into the page cache of a root-owned read-only file viaauthencesn-ESN stray writes.Set SKBFL_SHARED_FRAG on the destination whenever frag descriptorswere actually moved from the source. skb_copy() and skb_copy_expand()share skb_copy_header() too but linearize all paged data into freshlyallocated head storage and emerge with nr_frags == 0, soskb_has_shared_frag() returns false on its own; they need no change.The same omission exists in skb_gro_receive() and skb_gro_receive_list().The former moves the incoming skb's frag descriptors into theaccumulator's last sub-skb via two paths (a direct frag-move loop andthe head_frag + memcpy path); the latter chains the incoming skb wholeonto p's frag_list. Downstream skb_segment() reads onlyskb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb'sshinfo as the nskb -- both p and lp must carry the marker.The same omission also exists in tcp_clone_payload(), which builds anMTU probe skb by moving frag descriptors from skbs on sk_write_queueinto a freshly allocated nskb. The helper falls into the same familyand warrants the same fix for consistency; no TCP TX-side in-placewriter is currently known to reach a user page through this gap, buta future consumer depending on the marker would regress silently.The same omission exists in skb_segment(): the per-iteration flagmerge takes only head_skb's flag, and the inner switch that rebindsfrag_skb to list_skb on head_skb-frags exhaustion does not fold thenew frag_skb's flag into nskb. Fold frag_skb's flag at both sitesso segments drawing frags from frag_list members carry the marker.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: skbuff: preserve shared-frag marker during coalescingskb_try_coalesce() can attach paged frags from @from to @to. If @fromhas SKBFL_SHARED_FRAG set, the resulting @to skb can contain the sameexternally-owned or page-cache-backed frags, but the shared-frag markeris currently lost.That breaks the invariant relied on by later in-place writers. Inparticular, ESP input checks skb_has_shared_frag() before decidingwhether an uncloned nonlinear skb can skip skb_cow_data(). If TCPreceive coalescing has moved shared frags into an unmarked skb, ESP cansee skb_has_shared_frag() as false and decrypt in place over page-cachebacked frags.Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers pagedfrags. The tailroom copy path does not need the marker because it copiesbytes into @to's linear data rather than transferring frag descriptors.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.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).
- azure-cli < 2.82.0-150400.14.23.1 (version in image is 2.66.0-150400.14.18.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, 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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:nfsd: fix heap overflow in NFSv4.0 LOCK replay cacheThe NFSv4.0 replay cache uses a fixed 112-byte inline buffer(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.This size was calculated based on OPEN responses and does not accountfor LOCK denied responses, which include the conflicting lock owner asa variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).When a LOCK operation is denied due to a conflict with an existing lockthat has a large owner, nfsd4_encode_operation() copies the full encodedresponse into the undersized replay buffer via read_bytes_from_xdr_buf()with no bounds check. This results in a slab-out-of-bounds write of upto 944 bytes past the end of the buffer, corrupting adjacent heap memory.This can be triggered remotely by an unauthenticated attacker with twocooperating NFSv4.0 clients: one sets a lock with a large owner string,then the other requests a conflicting lock to provoke the denial.We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a fullopaque, but that would increase the size of every stateowner, when mostlockowners are not that large.Instead, fix this by checking the encoded response length againstNFSD4_REPLAY_ISIZE before copying into the replay buffer. If theresponse is too large, set rp_buflen to 0 to skip caching the replaypayload. The status is still cached, and the client already received thecorrect response on the original request.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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: 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:macvlan: fix error recovery in macvlan_common_newlink()valis provided a nice repro to crash the kernel: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 sourceip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20ping -c1 -I p1 1.2.3.4He also gave a very detailed analysis:The issue is triggered when a new macvlan link is created withMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (orMACVLAN_MACADDR_SET) parameter, lower device already has a macvlanport and register_netdevice() called from macvlan_common_newlink()fails (e.g. because of the invalid link name).In this case macvlan_hash_add_source is called frommacvlan_change_sources() / macvlan_common_newlink():This adds a reference to vlan to the port's vlan_source_hash usingmacvlan_source_entry.vlan is a pointer to the priv data of the link that is being created.When register_netdevice() fails, the error is returned frommacvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; }and free_netdev() is called, causing a kvfree() on the structnet_device that is still referenced in the source entry attached tothe lower device's macvlan port.Now all packets sent on the macvlan port with a matching source macaddress will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources()regardless of @create value whenever "goto destroy_macvlan_port;"path is taken.Many thanks to valis for following up on this issue.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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:fuse: reject oversized dirents in page cachefuse_add_dirent_to_cache() computes a serialized dirent size from theserver-controlled namelen field and copies the dirent into a singlepage-cache page. The existing logic only checks whether the dirent fitsin the remaining space of the current page and advances to a fresh pageif not. It never checks whether the dirent itself exceeds PAGE_SIZE.As a result, a malicious FUSE server can return a dirent withnamelen=4095, producing a serialized record size of 4120 bytes. On 4 KiBpage systems this causes memcpy() to overflow the cache page by 24 bytesinto the following kernel page.Reject dirents that cannot fit in a single page before copying them intothe readdir cache.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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: 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-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 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).
- azure-cli < 2.82.0-150400.14.23.1 (version in image is 2.66.0-150400.14.18.1).
-
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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, no limit was present on the number of pipelined requests that could be queued. An attacker may be able to use pipelined requests to use excessive amounts of memory, potentially leading to DoS. This vulnerability is fixed in 3.14.1.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, if an attacker sends large incomplete websocket frame payloads, it may be possible to bypass the usual size limits on memory use. This vulnerability is fixed in 3.14.1.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, it is possible to bypass the max_line_size check in parts of an HTTP request in the C parser. If using the optimised C parser (the default in pre-built wheels), then an attacker may be able to send oversized lines through the HTTP parser and use an excessive amount of memory, potentially leading to DoS. This vulnerability is fixed in 3.14.1.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 unprivileged local user can do privileged policy managementAn unprivileged local user can load, replace, and remove profiles byopening the apparmorfs interfaces, via a confused deputy attack, bypassing the opened fd to a privileged process, and getting theprivileged process to write to the interface.This does require a privileged target that can be manipulated to dothe write for the unprivileged process, but once such access isachieved full policy management is possible and all the possibleimplications that implies: removing confinement, DoS of system ortarget applications by denying all execution, by-passing theunprivileged user namespace restriction, to exploiting kernel bugs fora local privilege escalation.The policy management interface can not have its permissions simplychanged from 0666 to 0600 because non-root processes need to be ableto load policy to different policy namespaces.Instead ensure the task writing the interface has privileges thatare a subset of the task that opened the interface. This is alreadydone via policy for confined processes, but unconfined can delegateaccess to the opened fd, by-passing the usual policy check.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: fix fanout UAF in packet_release() via NETDEV_UP race`packet_release()` has a race window where `NETDEV_UP` can re-register asocket into a fanout group's `arr[]` array. The re-registration is notcleaned up by `fanout_release()`, leaving a dangling pointer in the fanoutarray.`packet_release()` does NOT zero `po->num` in its `bind_lock` section.After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex`still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`that already found the socket in `sklist` can re-register the hook.For fanout sockets, this re-registration calls `__fanout_link(sk, po)`which adds the socket back into `f->arr[]` and increments `f->num_members`,but does NOT increment `f->sk_ref`.The fix sets `po->num` to zero in `packet_release` while `bind_lock` isheld to prevent NETDEV_UP from linking, preventing the race window.This bug was found following an additional audit with Claude Code basedon CVE-2025-38617.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.14.0, using ``CookieJar.load()`` with untrusted input may allow arbitrary code execution. Most applications using this function will be doing so with the user's own data, so this is unlikely to affect many applications. Version 3.14.0 patches the issue. If an application does allow attacker controlled files to be loaded, a workaround on older releases would be to sanitize the files before loading.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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).
- docker > 0-0 (version in image is 28.5.1_ce-150000.247.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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_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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- grub2 > 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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: 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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: 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.0, attacker-controlled input included into multipart/payload headers can be used to modify a request to inject additional headers or similar. In the unlikely situation that an application is passing user-controlled strings into MultipartWriter.append(headers=...) or Payload.headers, then an attacker may be able to modify the request to inject headers or change the contents of the request. This vulnerability is fixed in 3.14.0.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, during cleanup it is possible for a compressed request body to be decompressed into memory in one chunk. An attacker may be able to send a compressed payload in specific situations that could be decompressed into memory, potentially leading to DoS (a zip bomb edge case). This vulnerability is fixed in 3.14.1.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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).
- azure-cli < 2.82.0-150400.14.23.1 (version in image is 2.66.0-150400.14.18.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: 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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_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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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/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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, multiple Host headers were allowed in aiohttp. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-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 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, insufficient restrictions in header/trailer handling could cause uncapped memory usage. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, a response with an excessive number of multipart headers may be allowed to use more memory than intended, potentially allowing a DoS vulnerability. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, when following redirects to a different origin, aiohttp drops the Authorization header, but retains the Cookie and Proxy-Authorization headers. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, the C parser (the default for most installs) accepted null bytes and control characters in response headers. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.14.0, cookies set with the `cookies` parameter on requests are sent after following a cross-origin redirect. If a developer uses the `cookies` parameter on a per-request basis then sensitive data might be leaked to an attacker if they manage to control a redirect. Version 3.14.0 patches the issue. If unable to upgrade, using a `Cookie` header in the `headers` parameter is not vulnerable.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, an attacker who controls the content_type parameter in aiohttp could use this to inject extra headers or similar exploits. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, the server_hostname TLS SNI check can be bypassed when an existing connection is reused. If an application makes multiple requests to the same domain, but with different per-request server_hostname parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check. This vulnerability is fixed in 3.14.1.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.60.1 (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: 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, DigestAuthMiddleware can send an authentication response after following a cross-origin redirect. This likely requires an open redirect vulnerability or similar on the target domain for an attacker to be able to execute. Further, the attacker is only receiving the digest, so should only be able to extract the user's credentials if the cryptography is weak or there is some kind of password reuse. This vulnerability is fixed in 3.14.1.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, an unbounded DNS cache could result in excessive memory usage possibly resulting in a DoS situation. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, an attacker who controls the reason parameter when creating a Response may be able to inject extra headers or similar exploits. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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: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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 6.4.0-150700.53.55.1 (version in image is 6.4.0-150700.53.52.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, for some multipart form fields, aiohttp read the entire field into memory before checking client_max_size. This issue has been patched in version 3.13.4.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.36.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: 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: 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-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-azure < 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).