-
Description: When a non-x86 platform is detected, cloud-init grants root access to a hardcoded url with a local IP address. To prevent this, cloud-init default configurations disable platform enumeration.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpng16-16 < 1.6.40-150600.3.17.1 (version in image is 1.6.40-150600.3.12.1).
-
Description: Vim before 9.2.0272 allows code execution that happens immediately upon opening a crafted file in the default configuration, because %{expr} injection occurs with tabpanel lacking P_MLE.
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.0110-150500.20.43.1).
-
Description: The email module, specifically the "BytesGenerator" class, didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. This is only applicable if using "LiteralHeader" writing headers that don't respect email folding rules, the new behavior will reject the incorrectly folded headers in "BytesGenerator".
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_6m1_0 < 3.6.15-150300.10.109.1 (version in image is 3.6.15-150300.10.106.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0276, a modeline sandbox bypass in Vim allows arbitrary OS command execution when a user opens a crafted file. The `complete`, `guitabtooltip` and `printheader` options are missing the `P_MLE` flag, allowing a modeline to be executed. Additionally, the `mapset()` function lacks a `check_secure()` call, allowing it to be abused from sandboxed expressions. Commit 9.2.0276 fixes the issue.
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.0110-150500.20.43.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-containers-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd-ctr > 0-0 (version in image is 1.7.29-150000.128.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpng16-16 < 1.6.40-150600.3.17.1 (version in image is 1.6.40-150600.3.12.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- tar < 1.34-150000.3.37.1 (version in image is 1.34-150000.3.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_modeThe local variable 'i' is initialized with -EINVAL, but the for loopimmediately overwrites it and -EINVAL is never returned.If no empty compression mode can be found, the function would return theout-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalidarray access in add_iaa_compression_mode().Fix both issues by returning either a valid index or -EINVAL.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/umad: Reject negative data_len in ib_umad_writeib_umad_write computes data_len from user-controlled count and theMAD header sizes. With a mismatched user MAD header size and RMPPheader length, data_len can become negative and reach ib_create_send_mad().This can make the padding calculation exceed the segment size and triggeran out-of-bounds memset in alloc_send_rmpp_list().Add an explicit check to reject negative data_len before creating thesend buffer.KASAN splat:[ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0[ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102[ 211.365867] ib_create_send_mad+0xa01/0x11b0[ 211.365887] ib_umad_write+0x853/0x1c80
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: A flaw was found in systemd. The systemd-machined service contains an Improper Access Control vulnerability due to insufficient validation of the class parameter in the RegisterMachine D-Bus (Desktop Bus) method. A local unprivileged user can exploit this by attempting to register a machine with a specific class value, which may leave behind a usable, attacker-controlled machine object. This allows the attacker to invoke methods on the privileged object, leading to the execution of arbitrary commands with root privileges on the host system.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsystemd0 < 254.27-150600.4.62.1 (version in image is 254.27-150600.4.55.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. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
- sle-module-containers-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd-ctr > 0-0 (version in image is 1.7.29-150000.128.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_addThe driver does not set hw->sta_data_size, which causes mac80211 toallocate insufficient space for driver private station data in__sta_info_alloc(). When rtl8xxxu_sta_add() accesses members ofstruct rtl8xxxu_sta_info through sta->drv_priv, this results in aslab-out-of-bounds write.KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter: BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346 Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12Set hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) duringprobe, similar to how hw->vif_data_size is configured. This ensuresmac80211 allocates sufficient space for the driver's per-stationprivate data.Tested on StarFive VisionFive 2 v1.2A board.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: If a BIND resolver is performing DNSSEC validation and encounters a maliciously crafted zone, the resolver may consume excessive CPU. Authoritative-only servers are generally unaffected, although there are circumstances where authoritative servers may make recursive queries (see: https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries).This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.46, 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.46-S1, and 9.20.9-S1 through 9.20.20-S1.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- bind-utils < 9.20.21-150700.3.18.1 (version in image is 9.20.18-150700.3.15.1).
-
Description: nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libnghttp2-14 < 1.64.0-150700.3.3.1 (version in image is 1.64.0-150700.1.5).
-
Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.3, the `pyasn1` library is vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding ASN.1 data with deeply nested structures. An attacker can supply a crafted payload containing thousands of nested `SEQUENCE` (`0x30`) or `SET` (`0x31`) tags with "Indefinite Length" (`0x80`) markers. This forces the decoder to recursively call itself until the Python interpreter crashes with a `RecursionError` or consumes all available memory (OOM), crashing the host application. This is a distinct vulnerability from CVE-2026-23490 (which addressed integer overflows in OID decoding). The fix for CVE-2026-23490 (`MAX_OID_ARC_CONTINUATION_OCTETS`) does not mitigate this recursion issue. Version 0.6.3 fixes this specific issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-pyasn1 < 0.4.2-150000.3.16.1 (version in image is 0.4.2-150000.3.13.1).
-
Description: A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain.This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-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.21-150700.3.18.1 (version in image is 9.20.18-150700.3.15.1).
-
Description: PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 ?4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC. This vulnerability is fixed in 2.12.0.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-PyJWT < 2.4.0-150200.3.11.1 (version in image is 2.4.0-150200.3.8.1).
-
Description: libexpat before 2.7.5 allows a NULL pointer dereference with empty external parameter entity content.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 < 2.7.1-150700.3.12.1 (version in image is 2.7.1-150700.3.9.2).
-
Description: libexpat before 2.7.5 allows an infinite loop while parsing DTD content.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 < 2.7.1-150700.3.12.1 (version in image is 2.7.1-150700.3.9.2).
-
Description: In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.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 > 0-0 (version in image is 2.38-150600.14.43.1).
-
Description: When an Expat parser with a registered ElementDeclHandler parses an inlinedocument type definition containing a deeply nested content model a C stackoverflow occurs.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: XZ Utils provide a general-purpose data-compression library plus command-line tools. Prior to version 5.8.3, if lzma_index_decoder() was used to decode an Index that contained no Records, the resulting lzma_index was left in a state where where a subsequent lzma_index_append() would allocate too little memory, and a buffer overflow would occur. This issue has been patched in version 5.8.3.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- liblzma5 > 0-0 (version in image is 5.4.1-150600.3.3.1).
-
Description: In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- sudo < 1.9.15p5-150600.3.15.1 (version in image is 1.9.15p5-150600.3.12.1).
-
Description: Issue summary: Converting an excessively large OCTET STRING value toa hexadecimal string leads to a heap buffer overflow on 32 bit platforms.Impact summary: A heap buffer overflow may lead to a crash or possiblyan attacker controlled code execution or other undefined behavior.If an attacker can supply a crafted X.509 certificate with an excessivelylarge OCTET STRING value in extensions such as the Subject Key Identifier(SKID) or Authority Key Identifier (AKID) which are being converted to hex,the size of the buffer needed for the result is calculated as multiplicationof the input length by 3. On 32 bit platforms, this multiplication may overflowresulting in the allocation of a smaller buffer and a heap buffer overflow.Applications and services that print or log contents of untrusted X.509certificates are vulnerable to this issue. As the certificates would haveto have sizes of over 1 Gigabyte, printing or logging such certificatesis a fairly unlikely operation and only 32 bit platforms are affected,this issue was assigned Low severity.The FIPS modules in 3.6, 3.5, 3.4, 3.3 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.16.1 (version in image is 1.1.1w-150700.11.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: aloop: Fix racy access at PCM triggerThe PCM trigger callback of aloop driver tries to check the PCM stateand stop the stream of the tied substream in the corresponding cable.Since both check and stop operations are performed outside the cablelock, this may result in UAF when a program attempts to triggerfrequently while opening/closing the tied stream, as spotted byfuzzers.For addressing the UAF, this patch changes two things:- It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses.- In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Prevent potential UAF in group creationThis commit prevents the possibility of a use after free issue in theGROUP_CREATE ioctl function, which arose as pointer to the group isaccessed in that ioctl function after storing it in the Xarray.A malicious userspace can second guess the handle of a group and tryto call GROUP_DESTROY ioctl from another thread around the same timeas GROUP_CREATE ioctl.To prevent the use after free exploit, this commit uses a mark on anentry of group pool Xarray which is added just before returning fromthe GROUP_CREATE ioctl function. The mark is checked for all ioctlsthat specify the group handle and so userspace won't be abe to deletea group that isn't marked yet.v2: Add R-bs and fixes tags
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Always remove class from active list before deleting in ets_qdisc_changezdi-disclosures@trendmicro.com says:The vulnerability is a race condition between `ets_qdisc_dequeue` and`ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.Attacker requires the capability to create new user and network namespacein order to trigger the bug.See my additional commentary at the end of the analysis.Analysis:static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack){... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc); } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0;}Comment:This happens because some of the classes have their qdiscs assigned toNULL, but remain in the active list. This commit fixes this issue by alwaysremoving the class from the active list before deleting and freeing itsassociated qdiscReproducer Steps(trimmed version of what was sent by zdi-disclosures@trendmicro.com)```DEV="${DEV:-lo}"ROOT_HANDLE="${ROOT_HANDLE:-1:}"BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2PING_BYTES="${PING_BYTES:-48}"PING_COUNT="${PING_COUNT:-200000}"PING_DST="${PING_DST:-127.0.0.1}"SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null}trap cleanup EXITip link set "$DEV" uptc qdisc del dev "$DEV" root 2>/dev/null || truetc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2tc -s qdisc ls dev $DEVping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 &tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc -s qdisc ls dev $DEVtc qdisc del dev "$DEV" parent ---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sva: invalidate stale IOTLB entries for kernel address spaceIntroduce a new IOMMU interface to flush IOTLB paging cache entries forthe CPU kernel address space. This interface is invoked from the x86architecture code that manages combined user and kernel page tables,specifically before any kernel page table page is freed and reused.This addresses the main issue with vfree() which is a common occurrenceand can be triggered by unprivileged users. While this resolves theprimary problem, it doesn't address some extremely rare case related tomemory unplug of memory that was present as reserved memory at boot, whichcannot be triggered by unprivileged users. The discussion can be found atthe link below.Enable SVA on x86 architecture since the IOMMU can now receivenotification to flush the paging cache before freeing the CPU kernel pagetable pages.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()in an interesting way [1]Crash happens in list_del_init()/INIT_LIST_HEAD() while writinglist->prev, while the prior write on list->next went well.static inline void INIT_LIST_HEAD(struct list_head *list){ WRITE_ONCE(list->next, list); // This went well WRITE_ONCE(list->prev, list); // Crash, @list has been freed.}Issue here is that rt6_uncached_list_del() did not attempt to lockul->lock, as list_empty(&rt->dst.rt_uncached) returnedtrue because the WRITE_ONCE(list->next, list) happened on the other CPU.We might use list_del_init_careful() and list_empty_careful(),or make sure rt6_uncached_list_del() always grabs the spinlockwhenever rt->dst.rt_uncached_list has been set.A similar fix is neeed for IPv4.[1] BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline] BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline] BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: netns cleanup_netCall Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 INIT_LIST_HEAD include/linux/list.h:46 [inline] list_del_init include/linux/list.h:296 [inline] rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853 addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] netif_close_many+0x29c/0x410 net/core/dev.c:1785 unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248 cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 803: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4953 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270 dst_alloc+0x105/0x170 net/core/dst.c:89 ip6_dst_alloc net/ipv6/route.c:342 [inline] icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333 mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recvmsg() unconditional requeueIf rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call atthe front of the recvmsg queue already has its mutex locked, it requeuesthe call - whether or not the call is already queued. The call may be onthe queue because MSG_PEEK was also passed and so the call was not dequeuedor because the I/O thread requeued it.The unconditional requeue may then corrupt the recvmsg queue, leading tothings like UAFs or refcount underruns.Fix this by only requeuing the call if it isn't already on the queue - andmoving it to the front if it is already queued. If we don't queue it, wehave to put the ref we obtained by dequeuing it.Also, MSG_PEEK doesn't dequeue the call so shouldn't callrxrpc_notify_socket() for the call if we didn't use up all the data on thequeue, so fix that also.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: annotate data-race around dev->workdev->work can re read locklessly in mISDN_read()and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.BUG: KCSAN: data-race in mISDN_ioctl / mISDN_readwrite to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000 -> 0x00000001
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): fix error messageSinc commit 79a6d1bfe114 ("can: gs_usb: gs_usb_receive_bulk_callback():unanchor URL on usb_submit_urb() error") a failing resubmit URB will printan info message.In the case of a short read where netdev has not yet been assigned,initialize as NULL to avoid dereferencing an undefined value. Also reportthe error value of the failed resubmit.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xferThe curr_xfer field is read by the IRQ handler without holding the lockto check if a transfer is in progress. When clearing curr_xfer in thecombined sequence transfer loop, protect it with the spinlock to preventa race with the interrupt handler.Protect the curr_xfer clearing at the exit path oftegra_qspi_combined_seq_xfer() with the spinlock to prevent a racewith the interrupt handler that reads this field.Without this protection, the IRQ handler could read a partially updatedcurr_xfer value, leading to NULL pointer dereference or use-after-free.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_u32: use skb_header_pointer_careful()skb_header_pointer() does not fully validate negative @offset values.Use skb_header_pointer_careful() instead.GangMin Kim provided a report and a repro fooling u32_classify():BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0net/sched/cls_u32.c:221
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/freeExynos Virtual Display driver performs memory alloc/free operationswithout lock protection, which easily causes concurrency problem.For example, use-after-free can occur in race scenario like this:``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ...```To prevent these vulns, at least in vidi_context, member variables relatedto memory alloc/free should be protected with ctx->lock.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix use-after-free in nf_tables_addchain()nf_tables_addchain() publishes the chain to table->chains vialist_add_tail_rcu() (in nft_chain_add()) before registering hooks.If nf_tables_register_hook() then fails, the error path callsnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()with no RCU grace period in between.This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain.Add synchronize_rcu() between nft_chain_del() and the chain destroyso that all RCU readers -- both dump threads and in-flight packetevaluation -- have finished before the chain is freed.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix refcount bug and potential UAF in perf_mmapSyzkaller reported a refcount_t: addition on 0; use-after-free warningin perf_mmap.The issue is caused by a race condition between a failing mmap() setupand a concurrent mmap() on a dependent event (e.g., using outputredirection).In perf_mmap(), the ring_buffer (rb) is allocated and assigned toevent->rb with the mmap_mutex held. The mutex is then released toperform map_range().If map_range() fails, perf_mmap_close() is called to clean up.However, since the mutex was dropped, another thread attaching tothis event (via inherited events or output redirection) can acquirethe mutex, observe the valid event->rb pointer, and attempt toincrement its reference count. If the cleanup path has alreadydropped the reference count to zero, this results in ause-after-free or refcount saturation warning.Fix this by extending the scope of mmap_mutex to cover themap_range() call. This ensures that the ring buffer initializationand mapping (or cleanup on failure) happens atomically effectively,preventing other threads from accessing a half-initialized ordying ring buffer.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: unconditionally bump set->nelems before insertionIn case that the set is full, a new element gets published then removedwithout waiting for the RCU grace period, while RCU reader can bewalking over it already.To address this issue, add the element transaction even if set is full,but toggle the set_full flag to report -ENFILE so the abort path safelyunwinds the set to its previous state.As for element updates, decrement set->nelems to restore it.A simpler fix is to call synchronize_rcu() in the error path.However, with a large batch adding elements to already maxed-out set,this could cause noticeable slowdown of such batches.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labelsIDLETIMER revision 0 rules reuse existing timers by label and always callmod_timer() on timer->timer.If the label was created first by revision 1 with XT_IDLETIMER_ALARM,the object uses alarm timer semantics and timer->timer is never initialized.Reusing that object from revision 0 causes mod_timer() on an uninitializedtimer_list, triggering debugobjects warnings and possible panic whenpanic_on_warn=1.Fix this by rejecting revision 0 rule insertion when an existing timer withthe same label is of ALARM type.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always walk all pending catchall elementsDuring transaction processing we might have more than one catchall element:1 live catchall element and 1 pending element that is coming as part of thenew batch.If the map holding the catchall elements is also going away, itsrequired to toggle all catchall elements and not just the first viablecandidate.Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libcap2 < 2.63-150400.3.6.1 (version in image is 2.63-150400.3.3.1).
-
Description: The webbrowser.open() API would accept leading dashes in the URL which could be handled as command line options for certain web browsers. New behavior rejects leading dashes. Users are recommended to sanitize URLs prior to passing to webbrowser.open().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written,2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process.This issue was fixed in version 4.10.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- sed > 0-0 (version in image is 4.9-150600.1.4).
-
Description: jq is a command-line JSON processor. An integer overflow vulnerability exists through version 1.8.1 within the jvp_string_append() and jvp_string_copy_replace_bad functions, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow). Any system evaluating untrusted jq queries is affected, as an attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings. The root cause is the absence of string size bounds checking, unlike arrays and objects which already have size limits. The issue has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: provide locking for v4_end_graceWriting to v4_end_grace can race with server shutdown and result inmemory being accessed after it was freed - reclaim_str_hashtbl inparticularly.We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that isheld while client_tracking_op->init() is called and that can wait foran upcall to nfsdcltrack which can write to v4_end_grace, resulting in adeadlock.nfsd4_end_grace() is also called by the landromat work queue and thisdoesn't require locking as server shutdown will stop the work and waitfor it before freeing anything that nfsd4_end_grace() might access.However, we must be sure that writing to v4_end_grace doesn't restartthe work item after shutdown has already waited for it. For this weadd a new flag protected with nn->client_lock. It is set only while itis safe to make client tracking calls, and v4_end_grace only scheduleswork while the flag is set with the spinlock held.So this patch adds a nfsd_net field "client_tracking_active" which isset as described. Another field "grace_end_forced", is set whenv4_end_grace is written. After this is set, and providingclient_tracking_active is set, the laundromat is scheduled.This "grace_end_forced" field bypasses other checks for whether thegrace period has finished.This resolves a race which can result in use-after-free.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()Blamed commit did not take care of VLAN encapsulationsas spotted by syzbot [1].Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Coalesce only linear skbvsock/virtio common tries to coalesce buffers in rx queue: if a linear skb(with a spare tail room) is followed by a small skb (length limited byGOOD_COPY_LEN = 128), an attempt is made to join them.Since the introduction of MSG_ZEROCOPY support, assumption that a small skbwill always be linear is incorrect. In the zerocopy case, data is lost andthe linear skb is appended with uninitialized kernel memory.Of all 3 supported virtio-based transports, only loopback-transport isaffected. G2H virtio-transport rx queue operates on explicitly linear skbs;see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2Gvhost-transport may allocate non-linear skbs, but only for sizes that arenot considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER invirtio_vsock_alloc_skb().Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) > 0guarantees last_skb is linear.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate theprivileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'root_squash' or 'all_squash' attributes that would normally be expected to apply to that client.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libnfsidmap1 < 1.0-150600.28.19.1 (version in image is 1.0-150600.28.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN specauthencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter thanthe minimum expected length, crypto_authenc_esn_decrypt() can advance pastthe end of the destination scatterlist and trigger a NULL pointer dereferencein scatterwalk_map_and_copy(), leading to a kernel panic (DoS).Add a minimum AAD length check to fail fast on invalid inputs.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: cap TX credit to local buffer sizeThe virtio transports derives its TX credit directly from peer_buf_alloc,which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.On the host side this means that the amount of data we are willing toqueue for a connection is scaled by a guest-chosen buffer size, ratherthan the host's own vsock configuration. A malicious guest can advertisea large buffer and read slowly, causing the host to allocate acorrespondingly large amount of sk_buff memory.The same thing would happen in the guest with a malicious host, sincevirtio transports share the same code base.Introduce a small helper, virtio_transport_tx_buf_size(), thatreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consumepeer_buf_alloc.This ensures the effective TX window is bounded by both the peer'sadvertised buffer and our own buf_alloc (already clamped tobuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peercannot force the other to queue more data than allowed by its ownvsock settings.On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with32 guest vsock connections advertising 2 GiB each and reading slowlydrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system onlyrecovered after killing the QEMU process. That said, if QEMU memory islimited with cgroups, the maximum memory used will be limited.With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiBOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guestremains responsive.Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.This change is limited to virtio_transport_common.c and thus affectsvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the"remote window intersected with local policy" behaviour that VMCI andHyper-V already effectively have.[Stefano: small adjustments after changing the previous patch][Stefano: tweak the commit message]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctlyThe existing allocation of scatterlists in omap_crypto_copy_sg_lists()was allocating an array of scatterlist pointers, not scatterlist objects,resulting in a 4x too small allocation.Use sizeof(*new_sg) to get the correct object size.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix UAF in xchk_btree_check_block_ownerWe cannot dereference bs->cur when trying to determine if bs->curaliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.Fix this by sampling before type before any freeing could happen.The correct temporal ordering was broken when we removed xfs_btnum_t.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTEWhen installing an emulated MMIO SPTE, do so *after* dropping/zapping theexisting SPTE (if it's shadow-present). While commit a54aa15c6bda3 wasright about it being impossible to convert a shadow-present SPTE to anMMIO SPTE due to a _guest_ write, it failed to account for writes to guestmemory that are outside the scope of KVM.E.g. if host userspace modifies a shadowed gPTE to switch from a memslotto emulted MMIO and then the guest hits a relevant page fault, KVM willinstall the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libavahi-client3 < 0.8-150600.15.15.1 (version in image is 0.8-150600.15.12.1).
-
Description: Issue summary: An uncommon configuration of clients performing DANE TLSA-basedserver authentication, when paired with uncommon server DANE TLSA records, mayresult in a use-after-free and/or double-free on the client side.Impact summary: A use after free can have a range of potential consequencessuch as the corruption of valid data, crashes or execution of arbitrary code.However, the issue only affects clients that make use of TLSA records with boththe PKIX-TA(0/PKIX-EE(1) certificate usages and the DANE-TA(2) certificateusage.By far the most common deployment of DANE is in SMTP MTAs for which RFC7672recommends that clients treat as 'unusable' any TLSA records that have the PKIXcertificate usages. These SMTP (or other similar) clients are not vulnerableto this issue. Conversely, any clients that support only the PKIX usages, andignore the DANE-TA(2) usage are also not vulnerable.The client would also need to be communicating with a server that publishes aTLSA RRset with both types of TLSA records.No FIPS modules are affected by this issue, the problem code is outside theFIPS 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.16.1 (version in image is 1.1.1w-150700.11.11.1).
-
Description: Under certain conditions, `named` may crash when processing a correctly signed query containing a TKEY record. The affected code can only be reached if an incoming request has a valid transaction signature (TSIG) from a key declared in the `named` configuration.This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-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.21-150700.3.18.1 (version in image is 9.20.18-150700.3.15.1).
-
Description: Issue summary: Applications using RSASVE key encapsulation to establisha secret encryption key can send contents of an uninitialized memory buffer toa malicious peer.Impact summary: The uninitialized buffer might contain sensitive data from theprevious execution of the application process which leads to sensitive dataleakage to an attacker.RSA_public_encrypt() returns the number of bytes written on success and -1on error. The affected code tests only whether the return value is non-zero.As a result, if RSA encryption fails, encapsulation can still return success tothe caller, set the output lengths, and leave the caller to use the contents ofthe ciphertext buffer as if a valid KEM ciphertext had been produced.If applications use EVP_PKEY_encapsulate() with RSA/RSASVE on anattacker-supplied invalid RSA public key without first validating that key,then this may cause stale or uninitialized contents of the caller-providedciphertext buffer to be disclosed to the attacker in place of the KEMciphertext.As a workaround calling EVP_PKEY_public_check() orEVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigatethe issue.The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libopenssl3 < 3.2.3-150700.5.31.1 (version in image is 3.2.3-150700.5.24.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.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.128.1).
-
Description: The fix for CVE-2026-0672, which rejected control characters in http.cookies.Morsel, was incomplete. The Morsel.update(), |= operator, and unpickling paths were not patched, allowing control characters to bypass input validation. Additionally, BaseCookie.js_output() lacked the output validation applied to BaseCookie.output().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Prevent recovery work from being queued during device removalUse disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()to ensure that no new recovery work items can be queued after deviceremoval has started. Previously, recovery work could be scheduled evenafter canceling existing work, potentially leading to use-after-freebugs if recovery accessed freed resources.Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to betterreflect its new behavior.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix UAF race between device unplug and FW event processingThe function panthor_fw_unplug() will free the FW memory sections.The problem is that there could still be pending FW events which are yetnot handled at this point. process_fw_events_work() can in this case tryto access said freed memory.Simply call disable_work_sync() to both drain and prevent futureinvocation of process_fw_events_work().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: correctly decode TTLM with default link mapTID-To-Link Mapping (TTLM) elements do not contain any link mappingpresence indicator if a default mapping is used and parsing needs to beskipped.Note that access points should not explicitly report an advertised TTLMwith a default mapping as that is the implied mapping if the element isnot included, this is even the case when switching back to the defaultmapping. However, mac80211 would incorrectly parse the frame and wouldalso read one byte beyond the end of the element.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error in mtk_xdp_setup()Reset eBPF program pointer to old_prog and do not decrease its ref-countif mtk_open routine in mtk_xdp_setup() fails.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shimThe root cause of this bug is that when 'bpf_link_put' reduces therefcount of 'shim_link->link.link' to zero, the resource is consideredreleased but may still be referenced via 'tr->progs_hlist' in'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in'bpf_shim_tramp_link_release' is deferred. During this window, anotherprocess can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.Based on Martin KaFai Lau's suggestions, I have created a simple patch.To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero.Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger:static void bpf_shim_tramp_link_release(struct bpf_link *link){ /* ... */ if (!shim_link->trampoline) return;+ msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline);}Before the patch, running a PoC easily reproduced the crash(almost 100%)with a call trace similar to KaiyanM's report.After the patch, the bug no longer occurs even after millions ofiterations.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clsact: Fix use-after-free in init/destroy rollback asymmetryFix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry.The latter is achieved by first fully initializing a clsact instance, andthen in a second step having a replacement failure for the new clsact qdiscinstance. clsact_init() initializes ingress first and then takes care of theegress part. This can fail midway, for example, via tcf_block_get_ext(). Uponfailure, the kernel will trigger the clsact_destroy() callback.Commit 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") details theway how the transition is happening. If tcf_block_get_ext on the q->ingress_blockends up failing, we took the tcx_miniq_inc reference count on the ingressside, but not yet on the egress side. clsact_destroy() tests whether the{ingress,egress}_entry was non-NULL. However, even in midway failure on thereplacement, both are in fact non-NULL with a valid egress_entry from theprevious clsact instance.What we really need to test for is whether the qdisc instance-specific ingressor egress side previously got initialized. This adds a small helper for checkingthe miniq initialization called mini_qdisc_pair_inited, and utilizes that uponclsact_destroy() in order to fix the use-after-free scenario. Convert theingress_destroy() side as well so both are consistent to each other.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix use-after-free in bond_xmit_broadcast()bond_xmit_broadcast() reuses the original skb for the last slave(determined by bond_is_last_slave()) and clones it for others.Concurrent slave enslave/release can mutate the slave list duringRCU-protected iteration, changing which slave is "last" mid-loop.This causes the original skb to be double-consumed (double-freed).Replace the racy bond_is_last_slave() check with a simple indexcomparison (i + 1 == slaves_count) against the pre-snapshot slavecount taken via READ_ONCE() before the loop. This preserves thezero-copy optimization for the last slave while making the "last"determination stable against concurrent list mutations.The UAF can trigger the following crash:==================================================================BUG: KASAN: slab-use-after-free in skb_cloneRead of size 8 at addr ffff888100ef8d40 by task exploit/147CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZYCall Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147:Freed by task 147:The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb>ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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.55.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: implement mremap in uacce_vm_ops to return -EPERMThe current uacce_vm_ops does not support the mremap operation ofvm_operations_struct. Implement .mremap to return -EPERM to remindusers.The reason we need to explicitly disable mremap is that when thedriver does not implement .mremap, it uses the default mremapmethod. This could lead to a risk scenario:An application might first mmap address p1, then mremap to p2,followed by munmap(p1), and finally munmap(p2). Since the defaultmremap copies the original vma's vm_private_data (i.e., q) to thenew vma, both munmap operations would trigger vma_close, causingq->qfr to be freed twice(qfr will be set to null here, so repeatedrelease is ok).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Fix buffer overflow in config retrievalThe scarlett2_usb_get_config() function has a logic error in theendianness conversion code that can cause buffer overflows whencount > 1.The code checks `if (size == 2)` where `size` is the total buffer size inbytes, then loops `count` times treating each element as u16 (2 bytes).This causes the loop to access `count * 2` bytes when the buffer onlyhas `size` bytes allocated.Fix by checking the element size (config_item->size) instead of thetotal buffer size. This ensures the endianness conversion matches theactual element type.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix use-after-free in lbs_free_adapter()The lbs_free_adapter() function uses timer_delete() (non-synchronous)for both command_timer and tx_lockup_timer before the structure isfreed. This is incorrect because timer_delete() does not wait forany running timer callback to complete.If a timer callback is executing when lbs_free_adapter() is called,the callback will access freed memory since lbs_cfg_free() frees thecontaining structure immediately after lbs_free_adapter() returns.Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler)access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields,which would all be use-after-free violations.Use timer_delete_sync() instead to ensure any running timer callbackhas completed before returning.This bug was introduced in commit 8f641d93c38a ("libertas: detect TXlockups and reset hardware") where del_timer() was used instead ofdel_timer_sync() in the cleanup path. The command_timer has had thesame issue since the driver was first written.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()Even though we check that we "should" be able to do lc_get_cumulative()while holding the device->al_lock spinlock, it may still fail,if some other code path decided to do lc_try_lock() with bad timing.If that happened, we logged "LOGIC BUG for enr=...",but still did not return an error.The rest of the code now assumed that this request has referencesfor the relevant activity log extents.The implcations are that during an active resync, mutual exclusivity ofresync versus application IO is not guaranteed. And a potential crashat this point may not realizs that these extents could have been targetof in-flight IO and would need to be resynced just in case.Also, once the request completes, it will give up activity log references itdoes not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().Fix:Do not crash the kernel for a condition that is harmless during normaloperation: also catch "e->refcnt == 0", not only "e == NULL"when being noisy about "al_complete_io() called on inactive extent %u\n".And do not try to be smart and "guess" whether something will work, thenbe surprised when it does not.Deal with the fact that it may or may not work. If it does not, remember apossible "partially in activity log" state (only possible for requests thatcross extent boundaries), and return an error code fromdrbd_al_begin_io_nonblock().A latter call for the same request will then resume from where we left off.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check metadata block offset is within rangeSyzkaller reports a "general protection fault in squashfs_copy_data"This is ultimately caused by a corrupted index look-up table, whichproduces a negative metadata block offset.This is subsequently passed to squashfs_copy_data (viasquashfs_read_metadata) where the negative offset causes an out of boundsaccess.The fix is to check that the offset is within range insquashfs_read_metadata. This will trap this and other cases.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix use-after-free in inet6_addr_del().syzbot reported use-after-free of inet6_ifaddr ininet6_addr_del(). [0]The cited commit accidentally moved ipv6_del_addr() formngtmpaddr before reading its ifp->flags for temporaryaddresses in inet6_addr_del().Let's move ipv6_del_addr() down to fix the UAF.[0]:BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f164cf8f749Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 Allocated by task 9593: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 6099: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free_freelist_hook mm/slub.c:2569 [inline] slab_free_bulk mm/slub.c:6696 [inline] kmem_cache_free_bulk mm/slub.c:7383 [inline] kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362 kfree_bulk include/linux/slab.h:830 [inline] kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523 kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline] kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801 process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257 process_scheduled_works kernel/workqu---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macroThe GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfsattributes:1. Off-by-one error: The loop condition used '<=' instead of '<', causing access beyond array bounds. Since array indices are 0-based and go from 0 to instances_count-1, the loop should use '<'.2. Missing NULL check: The code dereferenced attr_name_kobj->name without checking if attr_name_kobj was NULL, causing a null pointer dereference in min_length_show() and other attribute show functions.The panic occurred when fwupd tried to read BIOS configuration attributes: Oops: general protection fault [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]Add a NULL check for attr_name_kobj before dereferencing and correctsthe loop boundary to match the pattern used elsewhere in the driver.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: validate DFA start states are in bounds in unpack_pdbStart states are read from untrusted data and used as indexes into theDFA state tables. The aa_dfa_next() function call in unpack_pdb() willaccess dfa->tables[YYTD_ID_BASE][start], and if the start state exceedsthe number of states in the DFA, this results in an out-of-bound read.================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...Reject policies with out-of-bounds start states during unpackingto prevent the issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: jq is a command-line JSON processor. In commits before 2f09060afab23fe9390cce7cb860b10416e1bf5f, the jv_parse_sized() API in libjq accepts a counted buffer with an explicit length parameter, but its error-handling path formats the input buffer using %s in jv_string_fmt(), which reads until a NUL terminator is found rather than respecting the caller-supplied length. This means that when malformed JSON is passed in a non-NUL-terminated buffer, the error construction logic performs an out-of-bounds read past the end of the buffer. The vulnerability is reachable by any libjq consumer calling jv_parse_sized() with untrusted input, and depending on memory layout, can result in memory disclosure or process termination. The issue has been patched in commit 2f09060afab23fe9390cce7cb860b10416e1bf5f.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix improper freeing of purex itemIn qla2xxx_process_purls_iocb(), an item is allocated viaqla27xx_copy_multiple_pkt(), which internally callsqla24xx_alloc_purex_item().The qla24xx_alloc_purex_item() function may return a pre-allocated itemfrom a per-adapter pool for small allocations, instead of dynamicallyallocating memory with kzalloc().An error handling path in qla2xxx_process_purls_iocb() incorrectly useskfree() to release the item. If the item was from the pre-allocatedpool, calling kfree() on it is a bug that can lead to memory corruption.Fix this by using the correct deallocation function,qla24xx_free_purex_item(), which properly handles both dynamicallyallocated and pre-allocated items.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0316, a command injection vulnerability in Vim's netbeans interface allows a malicious netbeans server to execute arbitrary Ex commands when Vim connects to it, via unsanitized strings in the defineAnnoType and specialKeys protocol messages. This vulnerability is fixed in 9.2.0316.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0110-150500.20.43.1).
-
Description: cloud-init through 25.1.2 includes the systemd socket unit cloud-init-hotplugd.socket with default SocketMode that grants 0666 permissions, making it world-writable. This is used for the "/run/cloud-init/hook-hotplug-cmd" FIFO. An unprivileged user could trigger hotplug-hook commands.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
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:ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()When snd_usb_create_mixer() fails, snd_usb_mixer_free() freesmixer->id_elems but the controls already added to the card stillreference the freed memory. Later when snd_card_register() runs,the OSS mixer layer calls their callbacks and hits a use-after-free read.Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025Fix by calling snd_ctl_remove() for all mixer controls before freeingid_elems. We save the next pointer first because snd_ctl_remove()frees the current element.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix double-free in nr_route_frame()In nr_route_frame(), old_skb is immediately freed without checking ifnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,the caller function will free old_skb again, causing a double-free bug.Therefore, to prevent this, we need to modify it to check whethernr_neigh->ax25 is NULL before freeing old_skb.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmitteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmitthrough slave devices, but does not update skb->dev to the slave devicebeforehand.When a gretap tunnel is a TEQL slave, the transmit path reachesiptunnel_xmit() which saves dev = skb->dev (still pointing to teql0master) and later calls iptunnel_xmit_stats(dev, pkt_len). Thisfunction does: get_cpu_ptr(dev->tstats)Since teql_master_setup() does not set dev->pcpu_stat_type toNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstatsfor teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computesNULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)Fix this by setting skb->dev = slave before callingnetdev_start_xmit(), so that tunnel xmit functions see the correctslave device with properly allocated tstats.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. If an IPv6 packet is injected into the interface,route_shortcircuit() is called and a NULL pointer dereference happens onneigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix this by adding an early check on route_shortcircuit() when protocolis ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here becauseVXLAN can be built-in even when IPv6 is built as a module.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: fix NULL pointer dereference in icmp_tag_validation()icmp_tag_validation() unconditionally dereferences the result ofrcu_dereference(inet_protos[proto]) without checking for NULL.The inet_protos[] array is sparse -- only about 15 of 256 protocolnumbers have registered handlers. When ip_no_pmtu_disc is set to 3(hardened PMTU mode) and the kernel receives an ICMP FragmentationNeeded error with a quoted inner IP header containing an unregisteredprotocol number, the NULL dereference causes a kernel panic insoftirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If theprotocol has no registered handler, return false since it cannotperform strict tag validation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Issue summary: During processing of a crafted CMS EnvelopedData messagewith KeyTransportRecipientInfo a NULL pointer dereference can happen.Impact summary: Applications that process attacker-controlled CMS data maycrash before authentication or cryptographic operations occur resulting inDenial of Service.When a CMS EnvelopedData message that uses KeyTransportRecipientInfo withRSA-OAEP encryption is processed, the optional parameters field ofRSA-OAEP SourceFunc algorithm identifier is examined without checkingfor its presence. This results in a NULL pointer dereference if the fieldis missing.Applications and services that call CMS_decrypt() on untrusted input(e.g., S/MIME processing or CMS-based protocols) are vulnerable.The FIPS modules in 3.6, 3.5, 3.4, 3.3 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.16.1 (version in image is 1.1.1w-150700.11.11.1).
-
Description: libexpat before 2.7.5 allows a NULL pointer dereference in the function setContext on retry after an earlier ouf-of-memory condition.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 < 2.7.1-150700.3.12.1 (version in image is 2.7.1-150700.3.9.2).
-
Description: Calling NSS-backed functions that support caching via nscd may call the nscd client side code and in the GNU C Library version 2.36 under high load on x86_64 systems, the client may call memcmp on inputs that are concurrently modified by other processes or threads and crash.The nscd client in the GNU C Library uses the memcmp function with inputs that may be concurrently modified by another thread, potentially resulting in spurious cache misses, which in itself is not a security issue. However in the GNU C Library version 2.36 an optimized implementation of memcmp was introduced for x86_64 which could crash when invoked with such undefined behaviour, turning this into a potential crash of the nscd client and the application that uses it. This implementation was backported to the 2.35 branch, making the nscd client in that branch vulnerable as well. Subsequently, the fix for this issue was backported to all vulnerable branches in the GNU C Library repository.It is advised that distributions that may have cherry-picked the memcpy SSE2 optimization in their copy of the GNU C Library, also apply the fix to avoid the potential crash in the nscd client.
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.43.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: ipc: fix use-after-free in ipc_msg_send_requestipc_msg_send_request() waits for a generic netlink reply using anipc_msg_table_entry on the stack. The generic netlink handler(handle_generic_event()/handle_response()) fills entry->response underipc_msg_table_lock, but ipc_msg_send_request() used to validate and freeentry->response without holding the same lock.Under high concurrency this allows a race where handle_response() iscopying data into entry->response while ipc_msg_send_request() has justfreed it, leading to a slab-use-after-free reported by KASAN inhandle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]Fix by:- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table.- Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock.- Returning NULL in the error path, preserving the original API semantics.This makes all accesses to entry->response consistent withhandle_response(), which already updates and fills the response bufferunder ipc_msg_table_lock, and closes the race that allowed the UAF.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix admin request_queue lifetimeThe namespaces can access the controller's admin request_queue, andstale references on the namespaces may exist after tearing down thecontroller. Ensure the admin request_queue is active by moving thecontroller's 'put' to after all controller references have been releasedto ensure no one is can access the request_queue. This fixes a reporteduse-after-free bug: BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: fix error propagation in efivar_entry_get()efivar_entry_get() always returns success even if the underlying__efivar_entry_get() fails, masking errors.This may result in uninitialized heap memory being copied to userspacein the efivarfs_file_read() path.Fix it by returning the error from __efivar_entry_get().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()In iscsit_dec_session_usage_count(), the function calls complete() whileholding the sess->session_usage_lock. Similar to the connection usage countlogic, the waiter signaled by complete() (e.g., in the session releasepath) may wake up and free the iscsit_session structure immediately.This creates a race condition where the current thread may attempt toexecute spin_unlock_bh() on a session structure that has already beendeallocated, resulting in a KASAN slab-use-after-free.To resolve this, release the session_usage_lock before calling complete()to ensure all dereferences of the sess pointer are finished before thewaiter is allowed to proceed with deallocation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Prevent excessive number of framesIn this case, the user constructed the parameters with maxpacksize 40for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffersize for each data URB is maxpacksize * packets, which in this exampleis 40 * 6 = 240; When the user performs a write operation to send audiodata into the ALSA PCM playback stream, the calculated number of framesis packsize[0] * packets = 264, which exceeds the allocated URB buffersize, triggering the out-of-bounds (OOB) issue reported by syzbot [1].Added a check for the number of single data URB frames when calculatingthe number of frames to prevent [1].[1]BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506Call Trace: copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()and/or mptcp_pm_nl_is_backup()Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()which is not RCU ready.list_splice_init_rcu() can not be called here while holding pernet->lockspinlock.Many thanks to Eulgyu Kim for providing a repro and testing our patches.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: A flaw was found in util-linux. Improper hostname canonicalization in the `login(1)` utility, when invoked with the `-h` option, can modify the supplied remote hostname before setting `PAM_RHOST`. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libblkid1 < 2.40.4-150700.4.10.1 (version in image is 2.40.4-150700.4.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/xattr: missing fdput() in fremovexattr error pathIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire afile reference but returns early without calling fdput() whenstrncpy_from_user() fails on the name argument. In multi-threaded processeswhere fdget() takes the slow path, this permanently leaks onefile reference per call, pinning the struct file and associated kernelobjects in memory. An unprivileged local user can exploit this to causekernel memory exhaustion. The issue was inadvertently fixed by commita71874379ec8 ("xattr: switch to CLASS(fd)").
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Disable works on hci_unregister_devThis make use of disable_work_* on hci_unregister_dev since the hci_dev isabout to be freed new submissions are not disarable.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Forget ranges when refining tnum after JSETSyzbot reported a kernel warning due to a range invariant violation onthe following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps.That path is unreachable at runtime: after insn 1, we know r0 != 0, butwith the sign extension on the jset, we would only fallthrough insn 2if r0 == 0. Unfortunately, is_branch_taken() isn't currently able tofigure this out, so the verifier walks all branches. The verifier thenrefines the register bounds using the second condition and we endup with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0)Improving the range refinement for JSET to cover all cases is tricky. Wealso don't expect many users to rely on JSET given LLVM doesn't generatethose instructions. So instead of improving the range refinement forJSETs, Eduard suggested we forget the ranges whenever we're narrowingtnums after a JSET. This patch implements that approach.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: debugfs: Fix legacy mode page table dump logicIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTRmaybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490...Avoid walking the page table if TT is not 00b or 01b.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "ipmi: fix msg stack when IPMI is disconnected"This reverts commit c608966f3f9c2dca596967501d00753282b395fc.This patch has a subtle bug that can cause the IPMI driver to go into aninfinite loop if the BMC misbehaves in a certain way. Apparentlycertain BMCs do misbehave this way because several reports have come inrecently about this.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() pathsThe usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()path is very broken.sys_prlimit64() does get_task_struct(tsk) but this only protects task_structitself. If tsk != current and tsk is not a leader, this process can exit/execand task_lock(tsk->group_leader) may use the already freed task_struct.Another problem is that sys_prlimit64() can race with mt-exec which changes->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)->group_leader may change between task_lock() and task_unlock().Change sys_prlimit64() to take tasklist_lock when necessary. This is notnice, but I don't see a better fix for -stable.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: nxp: imx8-isi: Fix streaming cleanup on releaseThe current implementation unconditionally callsmxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This canlead to situations where any release call (like from a simple"v4l2-ctl -l") may release a currently streaming queue when called onsuch a device.This is reproducible on an i.MX8MP board by streaming from an ISIcapture device using gstreamer: gst-launch-1.0 -v v4l2src device=/dev/videoX ! \ video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \ fakesinkWhile this stream is running, querying the caps of the same deviceprovokes the error state: v4l2-ctl -l -d /dev/videoXThis results in the following trace:[ 155.452152] ------------[ cut here ]------------[ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6[ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT[ 157.064369] Hardware name: imx8mp_board_01 (DT)[ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi][ 157.087126] sp : ffff800080003ee0[ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000[ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50[ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000[ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000[ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000[ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38[ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000[ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000[ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200[ 157.161850] Call trace:[ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)[ 157.170319] __handle_irq_event_percpu+0x58/0x218[ 157.175029] handle_irq_event+0x54/0xb8[ 157.178867] handle_fasteoi_irq+0xac/0x248[ 157.182968] handle_irq_desc+0x48/0x68[ 157.186723] generic_handle_domain_irq+0x24/0x38[ 157.191346] gic_handle_irq+0x54/0x120[ 157.195098] call_on_irq_stack+0x24/0x30[ 157.199027] do_interrupt_handler+0x88/0x98[ 157.203212] el0_interrupt+0x44/0xc0[ 157.206792] __el0_irq_handler_common+0x18/0x28[ 157.211328] el0t_64_irq_handler+0x10/0x20[ 157.215429] el0t_64_irq+0x198/0x1a0[ 157.219009] ---[ end trace 0000000000000000 ]---Address this issue by moving the streaming preparation and cleanup tothe vb2 .prepare_streaming() and .unprepare_streaming() operations. Thisalso simplifies the driver by allowing direct usage of thevb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal ofthe manual cleanup from mxc_isi_video_release().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Add devm release action to safely tear down CTWhen a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATEflag, the driver initiates TLB invalidation requests via the CTB mechanismwhile releasing the BO. However a premature release of the CTB BO can leadto system crashes, as observed in:Oops: Oops: 0000 [#1] SMP NOPTIRIP: 0010:h2g_write+0x2f3/0x7c0 [xe]Call Trace: guc_ct_send_locked+0x8b/0x670 [xe] xe_guc_ct_send_locked+0x19/0x60 [xe] send_tlb_invalidation+0xb4/0x460 [xe] xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe] ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe] ggtt_node_remove+0x110/0x140 [xe] xe_ggtt_node_remove+0x40/0xa0 [xe] xe_ggtt_remove_bo+0x87/0x250 [xe]Introduce a devm-managed release action during xe_guc_ct_init() andxe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement beforeresource deallocation, preventing the use-after-free scenario.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix rcu protection in md_wakeup_threadWe attempted to use RCU to protect the pointer 'thread', but directlypassed the value when calling md_wakeup_thread(). This means that theRCU pointer has been acquired before rcu_read_lock(), which rendersrcu_read_lock() ineffective and could lead to a use-after-free.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()Don't add BO to the vdev->bo_list in ivpu_gem_create_object().When failure happens inside drm_gem_shmem_create(), the BO is notfully created and ivpu_gem_bo_free() callback will not be calledcausing a deleted BO to be left on the list.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslotReject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that wasinitially created with a guest_memfd binding, as KVM doesn't supporttoggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enablingKVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.Failure to reject the new memslot results in a use-after-free due to KVMnot unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLYchange is easy enough, and can/will be done as a hardening measure (inanticipation of KVM supporting dirty logging on guest_memfd at some point),but fixing the use-after-free would only address the immediate symptom. ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745 CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5c0 kasan_report+0xb4/0xe0 kvm_gmem_release+0x362/0x400 [kvm] __fput+0x2fa/0x9d0 task_work_run+0x12c/0x200 do_exit+0x6ae/0x2100 do_group_exit+0xa8/0x230 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0x737/0x740 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 Allocated by task 745 on cpu 6 at 9.746971s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_kmalloc+0x77/0x90 kvm_set_memory_region.part.0+0x652/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 745 on cpu 6 at 9.747467s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x3b/0x60 kfree+0xf5/0x440 kvm_set_memslot+0x3c2/0x1160 [kvm] kvm_set_memory_region.part.0+0x86a/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: avoid deadlock on fallback while reinjectingJakub reported an MPTCP deadlock at fallback time: WARNING: possible recursive locking detected 6.18.0-rc7-virtme #1 Not tainted -------------------------------------------- mptcp_connect/20858 is trying to acquire lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280 but task is already holding lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&msk->fallback_lock); lock(&msk->fallback_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by mptcp_connect/20858: #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0 #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0 #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 stack backtrace: CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full) Hardware name: Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0x6f/0xa0 print_deadlock_bug.cold+0xc0/0xcd validate_chain+0x2ff/0x5f0 __lock_acquire+0x34c/0x740 lock_acquire.part.0+0xbc/0x260 _raw_spin_lock_bh+0x38/0x50 __mptcp_try_fallback+0xd8/0x280 mptcp_sendmsg_frag+0x16c2/0x3050 __mptcp_retrans+0x421/0xaa0 mptcp_release_cb+0x5aa/0xa70 release_sock+0xab/0x1d0 mptcp_sendmsg+0xd5b/0x1bc0 sock_write_iter+0x281/0x4d0 new_sync_write+0x3c5/0x6f0 vfs_write+0x65e/0xbb0 ksys_write+0x17e/0x200 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fa5627cbc5e Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005 RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920 R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9cThe packet scheduler could attempt a reinjection after receiving anMP_FAIL and before the infinite map has been transmitted, causing adeadlock since MPTCP needs to do the reinjection atomically from WRTfallback.Address the issue explicitly avoiding the reinjection in the criticalscenario. Note that this is the only fallback critical section thatcould potentially send packets and hit the double-lock.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Discard Beacon frames to non-broadcast addressBeacon frames are required to be sent to the broadcast address, see IEEEStd 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frameshall be set to the broadcast address"). A unicast Beacon frame might beused as a targeted attack to get one of the associated STAs to dosomething (e.g., using CSA to move it to another channel). As such, itis better have strict filtering for this on the received side anddiscard all Beacon frames that are sent to an unexpected address.This is even more important for cases where beacon protection is used.The current implementation in mac80211 is correctly discarding unicastBeacon frames if the Protected Frame bit in the Frame Control field isset to 0. However, if that bit is set to 1, the logic used for checkingfor configured BIGTK(s) does not actually work. If the driver does nothave logic for dropping unicast Beacon frames with Protected Frame bit1, these frames would be accepted in mac80211 processing as valid Beaconframes even though they are not protected. This would allow beaconprotection to be bypassed. While the logic for checking beaconprotection could be extended to cover this corner case, a more genericcheck for discard all Beacon frames based on A1=unicast address coversthis without needing additional changes.Address all these issues by dropping received Beacon frames if they aresent to a non-broadcast address.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:counter: interrupt-cnt: Drop IRQF_NO_THREAD flagAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, asCONFIG_PROVE_RAW_LOCK_NESTING warns:=============================[ BUG: Invalid wait context ]6.18.0-rc1+git... #1-----------------------------some-user-space-process/1251 is trying to lock:(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]other info that might help us debug this:context-{2:2}no locks held by some-user-space-process/....stack backtrace:CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPTCall trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq... and Sebastian correctly points out. Remove IRQF_NO_THREAD as analternative to switching to raw_spinlock_t, because the latter would limitall potential nested locks to raw_spinlock_t only.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix NULL dereference on root when tracing inode evictionWhen evicting an inode the first thing we do is to setup tracing for it,which implies fetching the root's id. But in btrfs_evict_inode() theroot might be NULL, as implied in the next check that we do inbtrfs_evict_inode().Hence, we either should set the ->root_objectid to 0 in case the root isNULL, or we move tracing setup after checking that the root is notNULL. Setting the rootid to 0 at least gives us the possibility to tracethis call even in the case when the root is NULL, so that's the solutiontaken here.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: dma-crossbar: fix device leak on am335x route allocationMake sure to drop the reference taken when looking up the crossbarplatform device during am335x route allocation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: lpc18xx-dmamux: fix device leak on route allocationMake sure to drop the reference taken when looking up the DMA muxplatform device during route allocation.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: xilinx: xdma: Fix regmap max_registerThe max_register field is assigned the size of the register memoryregion instead of the offset of the last register.The result is that reading from the regmap via debugfs can causea segmentation fault:tail /sys/kernel/debug/regmap/xdma.1.auto/registersUnable to handle kernel paging request at virtual address ffff800082f70000Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault[...]Call trace: regmap_mmio_read32le+0x10/0x30 _regmap_bus_reg_read+0x74/0xc0 _regmap_read+0x68/0x198 regmap_read+0x54/0x88 regmap_read_debugfs+0x140/0x380 regmap_map_read_file+0x30/0x48 full_proxy_read+0x68/0xc8 vfs_read+0xcc/0x310 ksys_read+0x7c/0x120 __arm64_sys_read+0x24/0x40 invoke_syscall.constprop.0+0x64/0x108 do_el0_svc+0xb0/0xd8 el0_svc+0x38/0x130 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198Code: aa1e03e9 d503201f f9400000 8b214000 (b9400000)---[ end trace 0000000000000000 ]---note: tail[1217] exited with irqs disablednote: tail[1217] exited with preempt_count 1Segmentation fault
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: stm32-usphyc: Fix off by one in probe()The "index" variable is used as an index into the usbphyc->phys[] arraywhich has usbphyc->nphys elements. So if it is equal to usbphyc->nphysthen it is one element out of bounds. The "index" comes from thedevice tree so it's data that we trust and it's unlikely to be wrong,however it's obviously still worth fixing the bug. Change the > to >=.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 modeWhen operating in HS200 or HS400 timing modes, reducing the clock frequencybelow 52MHz will lead to link broken as the Rockchip DWC MSHC controllerrequires maintaining a minimum clock of 52MHz in these modes.Add a check to prevent illegal clock reduction through debugfs:root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clockroot@debian:/# [ 30.090146] mmc0: running CQE recoverymmc0: cqhci: Failed to haltmmc0: cqhci: spurious TCN for tag 0WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24Modules linked in:CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPTHardware name: Rockchip RK3588 EVB1 V10 Board (DT)Workqueue: kblockd blk_mq_run_work_fnpstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : cqhci_irq+0x254/0x818lr : cqhci_irq+0x254/0x818...
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wlcore: ensure skb headroom before skb_pushThis avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom isless than needed (typically 110 - 94 = 16 bytes).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: ocb: skip rx_no_sta when interface is not joinedieee80211_ocb_rx_no_sta() assumes a valid channel context, which is onlypresent after JOIN_OCB.RX may run before JOIN_OCB is executed, in which case the OCB interfaceis not operational. Skip RX peer handling when the interface is notjoined to avoid warnings in the RX path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't WARN for connections on invalid channelsIt's not clear (to me) how exactly syzbot managed to hit this,but it seems conceivable that e.g. regulatory changed and hasdisabled a channel between scanning (channel is checked to beusable by cfg80211_get_ies_channel_number) and connecting onthe channel later.With one scenario that isn't covered elsewhere described above,the warning isn't good, replace it with a (more informative)error message.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: Fix alignment fault in rtw_core_enable_beacon()rtw_core_enable_beacon() reads 4 bytes from an address that is not amultiple of 4. This results in a crash on some systems.Do 1 byte reads/writes instead.Unable to handle kernel paging request at virtual address ffff8000827e0522Mem abort info: ESR = 0x0000000096000021 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment faultData abort info: ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000005492000[ffff8000827e0522] pgd=0000000000000000, p4d=10000001021d9403, pud=10000001021da403, pmd=100000011061c403, pte=00780000f3200f13Internal error: Oops: 0000000096000021 [#1] SMPModules linked in: [...] rtw88_8822ce rtw88_8822c rtw88_pci rtw88_core [...]CPU: 0 UID: 0 PID: 73 Comm: kworker/u32:2 Tainted: G W 6.17.9 #1-NixOS VOLUNTARYTainted: [W]=WARNHardware name: FriendlyElec NanoPC-T6 LTS (DT)Workqueue: phy0 rtw_c2h_work [rtw88_core]pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : rtw_pci_read32+0x18/0x40 [rtw88_pci]lr : rtw_core_enable_beacon+0xe0/0x148 [rtw88_core]sp : ffff800080cc3ca0x29: ffff800080cc3ca0 x28: ffff0001031fc240 x27: ffff000102100828x26: ffffd2cb7c9b4088 x25: ffff0001031fc2c0 x24: ffff000112fdef00x23: ffff000112fdef18 x22: ffff000111c29970 x21: 0000000000000001x20: 0000000000000001 x19: ffff000111c22040 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd2cb6507c090x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000x2 : 0000000000007f10 x1 : 0000000000000522 x0 : ffff8000827e0522Call trace: rtw_pci_read32+0x18/0x40 [rtw88_pci] (P) rtw_hw_scan_chan_switch+0x124/0x1a8 [rtw88_core] rtw_fw_c2h_cmd_handle+0x254/0x290 [rtw88_core] rtw_c2h_work+0x50/0x98 [rtw88_core] process_one_work+0x178/0x3f8 worker_thread+0x208/0x418 kthread+0x120/0x220 ret_from_fork+0x10/0x20Code: d28fe202 8b020000 f9524400 8b214000 (b9400000)---[ end trace 0000000000000000 ]---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Validate sp before freeing associated memorySystem crash with the following signature[154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete[154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3.[154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5.[154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed - 0078 0080 0000.[154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed - 0078 00a0 0000.[154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).[154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).[154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8[154565.553080] #PF: supervisor read access in kernel mode[154565.553082] #PF: error_code(0x0000) - not-present page[154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0[154565.553089] Oops: 0000 1 PREEMPT SMP PTI[154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1[154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024[154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx][154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b[154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286[154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002[154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47[154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a[154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0[154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000[154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000[154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0[154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[154565.553159] PKRU: 55555554[154565.553160] Call Trace:[154565.553162] [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df[154565.553172] ? show_trace_log_lvl+0x1c4/0x2df[154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx][154565.553215] ? __die_body.cold+0x8/0xd[154565.553218] ? page_fault_oops+0x134/0x170[154565.553223] ? snprintf+0x49/0x70[154565.553229] ? exc_page_fault+0x62/0x150[154565.553238] ? asm_exc_page_fault+0x22/0x30Check for sp being non NULL before freeing any associated memory
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix reservation leak in some error paths when inserting inline extentIf we fail to allocate a path or join a transaction, we return from__cow_file_range_inline() without freeing the reserved qgroup data,resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data()in such cases.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix crash when adding interface under a lagCommit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag")fixed a similar issue in the lan966x driver caused by a NULL pointer dereference.The ocelot_set_aggr_pgids() function in the ocelot driver has similar logicand is susceptible to the same crash.This issue specifically affects the ocelot_vsc7514.c frontend, which leavesunused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected asit uses the DSA framework which registers all ports.Fix this by checking if the port pointer is valid before accessing it.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: check that server is running in unlock_filesystemIf we are trying to unlock the filesystem via an administrativeinterface and nfsd isn't running, it crashes the server. Thishappens currently because nfsd4_revoke_states() access statestructures (eg., conf_id_hashtbl) that has been freed as a partof the server shutdown.[ 59.465072] Call trace:[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd][ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd][ 59.466780] vfs_write+0x1f0/0x938[ 59.467088] ksys_write+0xfc/0x1f8[ 59.467395] __arm64_sys_write+0x74/0xb8[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8[ 59.468177] do_el0_svc+0x154/0x1d8[ 59.468489] el0_svc+0x40/0xe0[ 59.468767] el0t_64_sync_handler+0xa0/0xe8[ 59.469138] el0t_64_sync+0x1ac/0x1b0Ensure this can't happen by taking the nfsd_mutex and checking thatthe server is still up, and then holding the mutex across the call tonfsd4_revoke_states().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovecCommit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")added ttag bounds checking and data_offsetvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validatewhether the command's data structures (cmd->req.sg and cmd->iov) havebeen properly initialized before processing H2C_DATA PDUs.The nvmet_tcp_build_pdu_iovec() function dereferences these pointerswithout NULL checks. This can be triggered by sending H2C_DATA PDUimmediately after the ICREQ/ICRESP handshake, beforesending a CONNECT command or NVMe write command.Attack vectors that trigger NULL pointer dereferences:1. H2C_DATA PDU sent before CONNECT -> both pointers NULL2. H2C_DATA PDU for READ command -> cmd->req.sg allocated, cmd->iov NULL3. H2C_DATA PDU for uninitialized command slot -> both pointers NULLThe fix validates both cmd->req.sg and cmd->iov before callingnvmet_tcp_build_pdu_iovec(). Both checks are required because:- Uninitialized commands: both NULL- READ commands: cmd->req.sg allocated, cmd->iov NULL- WRITE commands: both allocated
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix error handling in the init_task on loadIf the init_task fails during a driver load, we end up without vports andnetdevs, effectively failing the entire process. In that state asubsequent reset will result in a crash as the service task attempts toaccess uninitialized resources. Following trace is from an error in theinit_task where the CREATE_VPORT (op 501) is rejected by the FW:[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)[40958.148190] idpf 0000:83:00.0: HW reset detected[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8...[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf][40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]...[40958.177932] Call Trace:[40958.178491] [40958.179040] process_one_work+0x226/0x6d0[40958.179609] worker_thread+0x19e/0x340[40958.180158] ? __pfx_worker_thread+0x10/0x10[40958.180702] kthread+0x10f/0x250[40958.181238] ? __pfx_kthread+0x10/0x10[40958.181774] ret_from_fork+0x251/0x2b0[40958.182307] ? __pfx_kthread+0x10/0x10[40958.182834] ret_from_fork_asm+0x1a/0x30[40958.183370] Fix the error handling in the init_task to make sure the service andmailbox tasks are disabled if the error happens during load. These arestarted in idpf_vc_core_init(), which spawns the init_task and has no wayof knowing if it failed. If the error happens on reset, followingsuccessful driver load, the tasks can still run, as that will allow thenetdevs to attempt recovery through another reset. Stop the PTP callbackseither way as those will be restarted by the call to idpf_vc_core_init()during a successful reset.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: 3com: 3c59x: fix possible null dereference in vortex_probe1()pdev can be null and free_ring: can be called in 1297 with a nullpdev.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of privmlx5e_priv is an unstable structure that can be memset(0) if profileattaching fails.Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on avalid netdev.On mlx5e_remove: Check validity of priv->profile, before attemptingto cleanup any resources that might be not there.This fixes a kernel oops in mlx5e_remove when switchdev mode fails dueto change profile failure.$ devlink dev eswitch set pci/0000:00:03.0 mode switchdevError: mlx5_core: Failed setting eswitch to offloads.dmesg:workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12$ devlink dev reload pci/0000:00:03.0 ==> oopsBUG: kernel NULL pointer dereference, address: 0000000000000370PGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0Call Trace: mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make calc_target() set t->paused, not just clear itCurrently calc_target() clears t->paused if the request shouldn't bepaused anymore, but doesn't ever set t->paused even though it's able todetermine when the request should be paused. Setting t->paused is leftto __submit_request() which is fine for regular requests but doesn'twork for linger requests -- since __submit_request() doesn't operateon linger requests, there is nowhere for lreq->t.paused to be set.One consequence of this is that watches don't get reestablished onpaused -> unpaused transitions in cases where requests have been pausedlong enough for the (paused) unwatch request to time out and for thesubsequent (re)watch request to enter the paused state. On top of thewatch not getting reestablished, rbd_reregister_watch() gets stuck withrbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_waitIt's waiting for lreq->reg_commit_wait to be completed, but for that tohappen the respective request needs to end up on need_resend_linger listand be kicked when requests are unpaused. There is no chance for thatif the request in question is never marked paused in the first place.The fact that rbd_dev->watch_mutex remains taken out forever thenprevents the image from getting unmapped -- "rbd unmap" would inevitablyhang in D state on an attempt to grab the mutex.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panelThe connector type for the DataImage SCF0700C48GGU18 panel is missing anddevm_drm_panel_bridge_add() requires connector type to be set. This leadsto a warning and a backtrace in the kernel log and panel does not work:"WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8"The warning is triggered by a check for valid connector type indevm_drm_panel_bridge_add(). If there is no valid connector typeset for a panel, the warning is printed and panel is not added.Fill in the missing connector type to fix the warning and makethe panel operational once again.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hv_netvsc: reject RSS hash key programming without RX indirection tableRSS configuration requires a valid RX indirection table. When the devicereports a single receive queue, rndis_filter_device_add() does notallocate an indirection table, accepting RSS hash key updates in thisstate leads to a hang.Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return-EOPNOTSUPP when the table is absent. This aligns set_rxfh with the devicecapabilities and prevents incorrect behavior.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: ensure safe queue release with state managementDirectly calling `put_queue` carries risks since it cannotguarantee that resources of `uacce_queue` have been fully releasedbeforehand. So adding a `stop_queue` operation for theUACCE_CMD_PUT_Q command and leaving the `put_queue` operation tothe final resource release ensures safety.Queue states are defined as follows:- UACCE_Q_ZOMBIE: Initial state- UACCE_Q_INIT: After opening `uacce`- UACCE_Q_STARTED: After `start` is issued via `ioctl`When executing `poweroff -f` in virt while accelerator are stillworking, `uacce_fops_release` and `uacce_remove` may executeconcurrently. This can cause `uacce_put_queue` within`uacce_fops_release` to access a NULL `ops` pointer. Therefore, addstate checks to prevent accessing freed pointers.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd: Fix memory leak in wbrf_record()The tmp buffer is allocated using kcalloc() but is not freed ifacpi_evaluate_dsm() fails. This causes a memory leak in the error path.Fix this by explicitly freeing the tmp buffer in the error handlingpath of acpi_evaluate_dsm().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Octeontx2-af: Add proper checks for fwdatafirmware populates MAC address, link modes (supported, advertised)and EEPROM data in shared firmware structure which kernel accessvia MAC block(CGX/RPM).Accessing fwdata, on boards booted with out MAC block leading tokernel panics.Internal error: Oops: 0000000096000005 [#1] SMP[ 10.460721] Modules linked in:[ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT[ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)[ 10.479793] Workqueue: events work_for_cpu_fn[ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 10.491124] pc : rvu_sdp_init+0x18/0x114[ 10.495051] lr : rvu_probe+0xe58/0x1d18
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: Fix race condition in hwspinlock irqsave routinePreviously, the address of the shared member '&map->spinlock_flags' waspassed directly to 'hwspin_lock_timeout_irqsave'. This creates a racecondition where multiple contexts contending for the lock could overwritethe shared flags variable, potentially corrupting the state for thecurrent lock owner.Fix this by using a local stack variable 'flags' to store the IRQ statetemporarily.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rsi: Fix memory corruption due to not set vif driver data sizeThe struct ieee80211_vif contains trailing space for vif driver data,when struct ieee80211_vif is allocated, the total memory size that isallocated is sizeof(struct ieee80211_vif) + size of vif driver data.The size of vif driver data is set by each WiFi driver as needed.The RSI911x driver does not set vif driver data size, no trailing spacefor vif driver data is therefore allocated past struct ieee80211_vif .The RSI911x driver does however use the vif driver data to store itsvif driver data structure "struct vif_priv". An access to vif->drv_privleads to access out of struct ieee80211_vif bounds and corruption ofsome memory.In case of the failure observed locally, rsi_mac80211_add_interface()would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv;vif_info->vap_id = vap_idx. This write corrupts struct fq_tin memberstruct list_head new_flows . The flow = list_first_entry(head, structfq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogusaddress, which when accessed causes a crash.The trigger is very simple, boot the machine with init=/bin/sh , mountdevtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1","ip link set wlan0 down" and the crash occurs.Fix this by setting the correct size of vif driver data, which is thesize of "struct vif_priv", so that memory is allocated and the drivercan store its driver data in it, instead of corrupting memory aroundit.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In esd_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inesd_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in esd_usb_close().Fix the memory leak by anchoring the URB in theesd_usb_read_bulk_callback() to the dev->rx_submitted anchor.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers areallocated, added to the priv->rx_submitted anchor and submitted. In thecomplete callback mcba_usb_read_bulk_callback(), the URBs are processed andresubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed bycalling usb_kill_anchored_urbs(&priv->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in themcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() errorIn commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fixURB memory leak"), the URB was re-anchored before usb_submit_urb() ings_usb_receive_bulk_callback() to prevent a leak of this URB duringcleanup.However, this patch did not take into account that usb_submit_urb() couldfail. The URB remains anchored andusb_kill_anchored_urbs(&parent->rx_submitted) in gs_can_close() loopsinfinitely since the anchor list never becomes empty.To fix the bug, unanchor the URB when an usb_submit_urb() error occurs,also print an info message.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Avoid truncating memory addressesOn 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmemallocations to be backed by addresses physical memory above the 32-bitaddress limit, as found while experimenting with larger VMSPLITconfigurations.This caused the qemu virt model to crash in the GICv3 driver, whichallocates the 'itt' object using GFP_KERNEL. Since all memory belowthe 4GB physical address limit is in ZONE_DMA in this configuration,kmalloc() defaults to higher addresses for ZONE_NORMAL, and theITS driver stores the physical address in a 32-bit 'unsigned long'variable.Change the itt_addr variable to the correct phys_addr_t type instead,along with all other variables in this driver that hold a physicaladdress.The gicv5 driver correctly uses u64 variables, while all other irqchipdrivers don't call virt_to_phys or similar interfaces. It's expected thatother device drivers have similar issues, but fixing this one issufficient for booting a virtio based guest.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()Memory allocated for struct vscsiblk_info in scsiback_probe() is notfreed in scsiback_remove() leading to potential memory leaks on remove,as well as in the scsiback_probe() error paths. Fix that by freeing itin scsiback_remove().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix crash on synthetic stacktrace field usageWhen creating a synthetic event based on an existing synthetic event thathad a stacktrace field and the new synthetic event used that field akernel crash occurred: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/triggerThe above creates a synthetic event that takes a stacktrace when a taskschedules out in a non-running state and passes that stacktrace to thesched_switch event when that task schedules back in. It triggers the"stack" synthetic event that has a stacktrace as its field (called "stack"). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/triggerThe above makes another synthetic event called "syscall_stack" thatattaches the first synthetic event (stack) to the sys_exit trace event andrecords the stacktrace from the stack event with the id of the system callthat is exiting.When enabling this event (or using it in a historgram): ~# echo 1 > events/synthetic/syscall_stack/enableProduces a kernel crash! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reason is that the stacktrace field is not labeled as such, and istreated as a normal field and not as a dynamic event that it is.In trace_event_raw_event_synth() the event is field is still treated as adynamic array, but the retrieval of the data is considered a normal field,and the reference is just the meta data:// Meta data is retrieved instead of a dynamic array---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: core: fix device reference leak on report presentSlimbus devices can be allocated dynamically upon reception ofreport-present messages.Make sure to drop the reference taken when looking up already registereddevices.Note that this requires taking an extra reference in case the device hasnot yet been registered and has to be allocated.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:intel_th: fix device leak on output open()Make sure to drop the reference taken when looking up the th deviceduring output device open() on errors and on close().Note that a recent commit fixed the leak in a couple of open() errorpaths but not all of them, and the reference is still leaking onsuccessful open().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: fix isolate sysfs check conditionuacce supports the device isolation feature. If the driverimplements the isolate_err_threshold_read andisolate_err_threshold_write callback functions, uacce will createsysfs files now. Users can read and configure the isolation policythrough sysfs. Currently, sysfs files are created as long as eitherisolate_err_threshold_read or isolate_err_threshold_write callbackfunctions are present.However, accessing a non-existent callback function may cause thesystem to crash. Therefore, intercept the creation of sysfs ifneither read nor write exists; create sysfs if either is supported,but intercept unsupported operations at the call site.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gue: Fix skb memleak with inner IP protocol 0.syzbot reported skb memleak below. [0]The repro generated a GUE packet with its inner protocol 0.gue_udp_recv() returns -guehdr->proto_ctype for "resubmit"in ip_protocol_deliver_rcu(), but this only works withnon-zero protocol number.Let's drop such packets.Note that 0 is a valid number (IPv6 Hop-by-Hop Option).I think it is not practical to encap HOPOPT in GUE, so oncesomeone starts to complain, we could pass down a resubmitflag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT[0]BUG: memory leakunreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uacce: fix cdev handling in the cleanup pathWhen cdev_device_add fails, it internally releases the cdev memory,and if cdev_device_del is then executed, it will cause a hang error.To fix it, we check the return value of cdev_device_add() and clearuacce->cdev to avoid calling cdev_device_del in the uacce_remove.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:migrate: correct lock ordering for hugetlb file foliosSyzbot has found a deadlock (analyzed by Lance Yang):1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquirefolio_lock.migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)!hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock!The migration path is the one taking locks in the wrong order according tothe documentation at the top of mm/rmap.c. So expand the scope of theexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.This is (mostly) how it used to be after commit c0d0381ade79. That wasremoved by 336bf30eb765 for both file & anon hugetlb pages when it shouldonly have been removed for anon hugetlb pages.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: limit BOND_MODE_8023AD to Ethernet devicesBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:leds: led-class: Only Add LED to leds_list when it is fully readyBefore this change the LED was added to leds_list before led_init_core()gets called adding it the list before led_classdev.set_brightness_work getsinitialized.This leaves a window where led_trigger_register() of a LED's defaulttrigger will call led_trigger_set() which calls led_set_brightness()which in turn will end up queueing the *uninitialized*led_classdev.set_brightness_work.This race gets hit by the lenovo-thinkpad-t14s EC driver which registers2 LEDs with a default trigger provided by snd_ctl_led.ko in quicksuccession. The first led_classdev_register() causes an async modprobe ofsnd_ctl_led to run and that async modprobe manages to exactly hitthe window where the second LED is on the leds_list without led_init_core()being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998Close the race window by moving the adding of the LED to leds_list toafter the led_init_core() call.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Fix restoration of SVE contextWhen SME is supported, Restoring SVE signal context can go wrong in afew ways, including placing the task into an invalid state where thekernel may read from out-of-bounds memory (and may potentially take afatal fault) and/or may kill the task with a SIGKILL.(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time.(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length.Fix (1) by setting TIF_SME when setting SVCR.SM. This also requiresensuring that the task's sme_state has been allocated, but as this couldcontain live ZA state, it should not be zeroed. Fix (2) by clearingSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME,and fp_type earlier, immediately after the allocation ofsve_state/sme_state, before the restore of the actual register state.This makes it easier to ensure that these are always modifiedconsistently, even if a fault is taken while reading the register datafrom the signal context. I do not expect any software to depend on theexact state restored when a fault is taken while reading the context.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Make the addrs_lock be per portMake the addrs_lock be per port, not per ipvlan dev.Initial code seems to be written in the assumption,that any address change must occur under RTNL.But it is not so for the case of IPv6. So1) Introduce per-port addrs_lock.2) It was needed to fix places where it was forgottento take lock (ipvlan_open/ipvlan_close)This appears to be a very minor problem though.Since it's highly unlikely that ipvlan_add_addr() willbe called on 2 CPU simultaneously. But nevertheless,this could cause:1) False-negative of ipvlan_addr_busy(): one interfaceiterated through all port->ipvlans + ipvlan->addrsunder some ipvlan spinlock, and another added IPunder its own lock. Though this is only possiblefor IPv6, since looks like only ipvlan_addr6_event() can becalled without rtnl_lock.2) Race since ipvlan_ht_addr_add(port) is called underdifferent ipvlan->addrs_lock locksThis should not affect performance, since add/remove IPis a rare situation and spinlock is not taken on fastpaths.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Allocate SSVE storage when restoring ZAThe code to restore a ZA context doesn't attempt to allocate the task'ssve_state before setting TIF_SME. Consequently, restoring a ZA contextcan place a task into an invalid state where TIF_SME is set but thetask's sve_state is NULL.In legitimate but uncommon cases where the ZA signal context was NOTcreated by the kernel in the context of the same task (e.g. if the taskis saved/restored with something like CRIU), we have no guarantee thatsve_state had been allocated previously. In these cases, userspace canenter streaming mode without trapping while sve_state is NULL, causing alater NULL pointer dereference when the kernel attempts to store theregister state:| # ./sigreturn-za| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000| Mem abort info:| ESR = 0x0000000096000046| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x06: level 2 translation fault| Data abort info:| ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000| CM = 0, WnR = 1, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000| Internal error: Oops: 0000000096000046 [#1] SMP| Modules linked in:| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT| Hardware name: linux,dummy-virt (DT)| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)| pc : sve_save_state+0x4/0xf0| lr : fpsimd_save_user_state+0xb0/0x1c0| sp : ffff80008070bcc0| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440| Call trace:| sve_save_state+0x4/0xf0 (P)| fpsimd_thread_switch+0x48/0x198| __switch_to+0x20/0x1c0| __schedule+0x36c/0xce0| schedule+0x34/0x11c| exit_to_user_mode_loop+0x124/0x188| el0_interrupt+0xc8/0xd8| __el0_irq_handler_common+0x18/0x24| el0t_64_irq_handler+0x10/0x1c| el0t_64_irq+0x198/0x19c| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)| ---[ end trace 0000000000000000 ]---Fix this by having restore_za_context() ensure that the task's sve_stateis allocated, matching what we do when taking an SME trap. Any liveSVE/SSVE state (which is restored earlier from a separate signalcontext) must be preserved, and hence this is not zeroed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loopCurrently this is checked before running the pending work. Normally thisis quite fine, as work items either end up blocking (which will create anew worker for other items), or they complete fairly quickly. But syzbotreports an issue where io-wq takes seemingly forever to exit, and with abit of debugging, this turns out to be because it queues a bunch of big(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn'tsupport ->read_iter(), loop_rw_iter() ends up handling them. Each readreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch ofthese pending, processing the whole chain can take a long time. Easilylonger than the syzbot uninterruptible sleep timeout of 140 seconds.This then triggers a complaint off the io-wq exit path:INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa02738f749RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000caRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98There's really nothing wrong here, outside of processing these readswill take a LONG time. However, we can speed up the exit by checking theIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot willexit the ring after queueing up all of these reads. Then once the firstitem is processed, io-wq will simply cancel the rest. That should avoidsyzbot running into this complaint again.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpuFor i.MX8MQ platform, the ADB in the VPUMIX domain has no separate resetand clock enable bits, but is ungated and reset together with the VPUs.So we can't reset G1 or G2 separately, it may led to the system hang.Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.Let imx8mq_vpu_power_notifier() do really vpu reset.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix data-race warning and potential load/store tearingFix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packetwhich is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds();and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;The lockless accesses to these to values aren't actually a problem as theread only needs an approximate time of last transmission for the purposesof deciding whether or not the transmission of a keepalive packet iswarranted yet.Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bitarch.Fix both of these by switching to an unsigned int for ->last_tx_at and onlystoring the LSW of the time64_t. It can then be reconstructed at needprovided no more than 68 years has elapsed since the last transmission.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: provide a net pointer to __skb_flow_dissect()After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")we have to provide a net pointer to __skb_flow_dissect(),either via skb->dev, skb->sk, or a user provided pointer.In the following case, syzbot was able to cook a bare skb.WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: avoid one data-race in l2tp_tunnel_del_work()We should read sk->sk_socket only when dealing with kernel sockets.syzbot reported the following data-race:BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_releasewrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246value changed: 0xffff88811b818000 -> 0x0000000000000000
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: annotate data-race in ndisc_router_discovery()syzbot found that ndisc_router_discovery() could read and writein6_dev->ra_mtu without holding a lock [1]This looks fine, IFLA_INET6_RA_MTU is best effort.Add READ_ONCE()/WRITE_ONCE() to document the race.Note that we might also reject illegal MTU values(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.[1]BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discoveryread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...value changed: 0x00000000 -> 0xe5400659
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INITA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH keyinitialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127The issue is triggered when sctp_auth_asoc_init_active_key() fails insctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, thecommand sequence is currently:- SCTP_CMD_PEER_INIT- SCTP_CMD_TIMER_STOP (T1_INIT)- SCTP_CMD_TIMER_START (T1_COOKIE)- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)- SCTP_CMD_ASSOC_SHKEY- SCTP_CMD_GEN_COOKIE_ECHOIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, whileasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set bySCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULLto be queued by sctp_datamsg_from_user().Since command interpretation stops on failure, no COOKIE_ECHO should beensent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has alreadybeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. Asa result, the DATA chunk can be transmitted together with the COOKIE_ECHOin sctp_outq_flush_data(), leading to the observed issue.Similar to the other places where it calls sctp_auth_asoc_init_active_key()right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEYimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and startingT1_COOKIE. This ensures that if shared key generation fails, authenticatedDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,giving the client another chance to process INIT_ACK and retry key setup.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix a race issue related to the operation on bpf_bound_progs listThe netdevsim driver lacks a protection mechanism for operations on thebpf_bound_progs list. When the nsim_bpf_create_prog() performslist_add_tail, it is possible that nsim_bpf_destroy_prog() issimultaneously performs list_del. Concurrent operations on the list maylead to list corruption and trigger a kernel crash as follows:[ 417.290971] kernel BUG at lib/list_debug.c:62![ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 417.291007] Workqueue: events bpf_prog_free_deferred[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0[ 417.291088] PKRU: 55555554[ 417.291091] Call Trace:[ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim][ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0[ 417.291178] process_one_work+0x18a/0x3a0[ 417.291188] worker_thread+0x27b/0x3a0[ 417.291197] ? __pfx_worker_thread+0x10/0x10[ 417.291207] kthread+0xe5/0x120[ 417.291214] ? __pfx_kthread+0x10/0x10[ 417.291221] ret_from_fork+0x31/0x50[ 417.291230] ? __pfx_kthread+0x10/0x10[ 417.291236] ret_from_fork_asm+0x1a/0x30[ 417.291246] Add a mutex lock, to prevent simultaneous addition and deletion operationson the list.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Set __nocfi on swsusp_arch_resume()A DABT is reported[1] on an android based system when resume from hiberate.This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()and does not have a CFI hash, but swsusp_arch_resume() will attempt toverify the CFI hash when calling a copy of swsusp_arch_suspend_exit().Given that there's an existing requirement that the entrypoint toswsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.textsection, we cannot fix this by marking swsusp_arch_suspend_exit() withSYM_FUNC_*(). The simplest fix for now is to disable the CFI check inswsusp_arch_resume().Mark swsusp_arch_resume() as __nocfi to disable the CFI check.[1][ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc[ 22.991934][ T1] Mem abort info:[ 22.991934][ T1] ESR = 0x0000000096000007[ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits[ 22.991934][ T1] SET = 0, FnV = 0[ 22.991934][ T1] EA = 0, S1PTW = 0[ 22.991934][ T1] FSC = 0x07: level 3 translation fault[ 22.991934][ T1] Data abort info:[ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000[ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper[ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP[ 22.991934][ T1] Dumping ftrace buffer:[ 22.991934][ T1] (ftrace buffer empty)[ 22.991934][ T1] Modules linked in:[ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419[ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)[ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344[ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344[ 22.991934][ T1] sp : ffffffc08006b960[ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000[ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820[ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000[ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058[ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004[ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000[ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000[ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b[ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530[ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000[ 22.991934][ T1] Call trace:[ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344[ 22.991934][ T1] hibernation_restore+0x158/0x18c[ 22.991934][ T1] load_image_and_restore+0xb0/0xec[ 22.991934][ T1] software_resume+0xf4/0x19c[ 22.991934][ T1] software_resume_initcall+0x34/0x78[ 22.991934][ T1] do_one_initcall+0xe8/0x370[ 22.991934][ T1] do_initcall_level+0xc8/0x19c[ 22.991934][ T1] do_initcalls+0x70/0xc0[ 22.991934][ T1] do_basic_setup+0x1c/0x28[ 22.991934][ T1] kernel_init_freeable+0xe0/0x148[ 22.991934][ T1] kernel_init+0x20/0x1a8[ 22.991934][ T1] ret_from_fork+0x10/0x20[ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)[catalin.marinas@arm.com: commit log updated by Mark Rutland]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpll: Prevent duplicate registrationsModify the internal registration helpers dpll_xa_ref_{dpll,pin}_add()to reject duplicate registration attempts.Previously, if a caller attempted to register the same pin multipletimes (with the same ops, priv, and cookie) on the same device, the coresilently increments the reference count and return success. This behavioris incorrect because if the caller makes these duplicate registrationsthen for the first one dpll_pin_registration is allocated and for othersthe associated dpll_pin_ref.refcount is incremented. During the firstunregistration the associated dpll_pin_registration is freed and forothers WARN is fired.Fix this by updating the logic to return `-EEXIST` if a matchingregistration is found to enforce a strict "register once" policy.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute namesThe hp-bioscfg driver attempts to register kobjects with empty names whenthe HP BIOS returns attributes with empty name strings. This causesmultiple kernel warnings: kobject: (00000000135fb5e6): attempted to be registered with empty name! WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310Add validation in hp_init_bios_buffer_attribute() to check if theattribute name is empty after parsing it from the WMI buffer. If empty,log a debug message and skip registration of that attribute, allowing themodule to continue processing other valid attributes.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: reset sparse-read state in osd_fault()When a fault occurs, the connection is abandoned, reestablished, and anypending operations are retried. The OSD client tracks the progress of asparse-read reply using a separate state machine, largely independent ofthe messenger's state.If a connection is lost mid-payload or the sparse-read state machinereturns an error, the sparse-read state is not reset. The OSD clientwill then interpret the beginning of a new reply as the continuation ofthe old one. If this makes the sparse-read machinery enter a failurestate, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on readTherefore, reset the sparse-read state in osd_fault(), ensuring retriesstart from a clean state.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add recursion protection in kernel stack trace recordingA bug was reported about an infinite recursion caused by tracing the rcuevents with the kernel stack trace trigger enabled. The stack trace codecalled back into RCU which then called the stack trace again.Expand the ftrace recursion protection to add a set of bits to protectevents from recursion. Each bit represents the context that the event isin (normal, softirq, interrupt and NMI).Have the stack trace code use the interrupt context to protect againstrecursion.Note, the bug showed an issue in both the RCU code as well as the tracingstacktrace code. This only handles the tracing stack trace side of thebug. The RCU fix will be handled separately.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: update last_gc only when GC has been performedCurrently last_gc is being updated everytime a new connection istracked, that means that it is updated even if a GC wasn't performed.With a sufficiently high packet rate, it is possible to always bypassthe GC, causing the list to grow infinitely.Update the last_gc value only when a GC has been actually performed.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Subtract size of xdp_frame from allowed metadata sizeThe xdp_frame structure takes up part of the XDP frame headroom,limiting the size of the metadata. However, in bpf_test_run, we don'ttake this into account, which makes it possible for userspace to supplya metadata size that is too large (taking up the entire headroom).If userspace supplies such a large metadata size in live packet mode,the xdp_update_frame_from_buff() call in xdp_test_run_init_page() callwill fail, after which packet transmission proceeds with anuninitialised frame structure, leading to the usual Bad Stuff.The commit in the Fixes tag fixed a related bug where the second checkin xdp_update_frame_from_buff() could fail, but did not add anyadditional constraints on the metadata size. Complete the fix by addingan additional check on the metadata size. Reorder the checks slightly tomake the logic clearer and add a comment.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: send: check for inline extents in range_is_hole_in_parent()Before accessing the disk_bytenr field of a file extent item we needto check if we are dealing with an inline extent.This is because for inline extents their data starts at the offset ofthe disk_bytenr field. So accessing the disk_bytenrmeans we are accessing inline data or in case the inline data is lessthan 8 bytes we can actually cause an invalidmemory access if this inline extent item is the first item in the leafor access metadata from other items.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix iloc.bh leak in ext4_xattr_inode_update_refThe error branch for ext4_xattr_inode_update_ref forget to release therefcount for iloc.bh. Find this when review code.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix memory leak in set_ssp_completeFix memory leak in set_ssp_complete() where mgmt_pending_cmd structuresare not freed after being removed from the pending list.Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") replacedmgmt_pending_foreach() calls with individual command handling but missedadding mgmt_pending_free() calls in both error and success paths ofset_ssp_complete(). Other completion functions like set_le_complete()were fixed correctly in the same commit.This causes a memory leak of the mgmt_pending_cmd structure and itsassociated parameter data for each SSP command that completes.Add the missing mgmt_pending_free(cmd) calls in both code paths to fixthe memory leak. Also fix the same issue in set_advertising_complete().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix segmentation of forwarding fraglist GROThis patch enhances GSO segment handling by properly checkingthe SKB_GSO_DODGY flag for frag_list GSO packets, addressinglow throughput issues observed when a station accesses IPv4servers via hotspots with an IPv6-only upstream interface.Specifically, it fixes a bug in GSO segmentation when forwardingGRO packets containing a frag_list. The function skb_segment_listcannot correctly process GRO skbs that have been converted by XLAT,since XLAT only translates the header of the head skb. Consequently,skbs in the frag_list may remain untranslated, resulting in protocolinconsistencies and reduced throughput.To address this, the patch explicitly sets the SKB_GSO_DODGY flagfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSOpackets as potentially modified after protocol translation. As aresult, GSO segmentation will avoid using skb_segment_list andinstead falls back to skb_segment for packets with the SKB_GSO_DODGYflag. This ensures that only safe and fully translated frag_listpackets are processed by skb_segment_list, resolving protocolinconsistencies and improving throughput when forwarding GRO packetsconverted by XLAT.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not strictly require dirty metadata threshold for metadata writepages[BUG]There is an internal report that over 1000 processes arewaiting at the io_schedule_timeout() of balance_dirty_pages(), causinga system hang and trigger a kernel coredump.The kernel is v6.4 kernel based, but the root problem still applies toany upstream kernel before v6.18.[CAUSE]From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup.So that means the only way to reduce the dirty pages of that cgroup isto writeback the dirty pages of btrfs btree inode, and only after thatthose processes can exit balance_dirty_pages().Now back to the btrfs part, btree_writepages() is responsible forwriting back dirty btree inode pages.The problem here is, there is a btrfs internal threshold that if thebtree inode's dirty bytes are below the 32M threshold, it will notdo any writeback.This behavior is to batch as much metadata as possible so we won't writeback those tree blocks and then later re-COW them again for anothermodification.This internal 32MiB is higher than the existing dirty page size (28MiB),meaning no writeback will happen, causing a deadlock between btrfs andcgroup:- Btrfs doesn't want to write back btree inode until more dirty pages- Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced.Thanks Jan Kara a lot for the analysis of the root cause.[ENHANCEMENT]Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on thebtree_inode"), btrfs btree inode pages will only be charged to the rootcgroup which should have a much larger limit than btrfs' 32MiBthreshold.So it should not affect newer kernels.But for all current LTS kernels, they are all affected by this problem,and backporting the whole AS_KERNEL_FILE may not be a good idea.Even for newer kernels I still think it's a good idea to getrid of the internal threshold at btree_writepages(), since for most casescgroup/MM has a better view of full system memory usage than btrfs' fixedthreshold.For internal callers using btrfs_btree_balance_dirty() since thatfunction is already doing internal threshold check, we don't need tobother them.But for external callers of btree_writepages(), just respect theirrequests and write back whatever they want, ignoring the internalbtrfs threshold to avoid such deadlock on btree inode dirty pagebalancing.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Fix memory leak in octep_device_setup()In octep_device_setup(), if octep_ctrl_net_init() fails, the functionreturns directly without unmapping the mapped resources and freeing theallocated configuration memory.Fix this by jumping to the unsupported_dev label, which performs thenecessary cleanup. This aligns with the error handling logic of otherpaths in this function.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rocker: fix memory leak in rocker_world_port_post_fini()In rocker_world_port_pre_init(), rocker_port->wpriv is allocated withkzalloc(wops->port_priv_size, GFP_KERNEL). However, inrocker_world_port_post_fini(), the memory is only freed whenwops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);Since rocker_ofdpa_ops does not implement port_post_fini callback(it is NULL), the wpriv memory allocated for each port is never freedwhen ports are removed. This leads to a memory leak ofsizeof(struct ofdpa_port) bytes per port on every device removal.Fix this by always calling kfree(rocker_port->wpriv) regardless ofwhether the port_post_fini callback exists.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix race between rfkill and nci_unregister_device().syzbot reported the splat below [0] without a repro.It indicates that struct nci_dev.cmd_wq had been destroyed beforenci_close_device() was called via rfkill.nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which(I think) was called from virtual_ncidev_close() when syzbot close()dan fd of virtual_ncidev.The problem is that nci_unregister_device() destroys nci_dev.cmd_wqfirst and then calls nfc_unregister_device(), which removes thedevice from rfkill by rfkill_unregister().So, the device is still visible via rfkill even after nci_dev.cmd_wqis destroyed.Let's unregister the device from rfkill first in nci_unregister_device().Note that we cannot call nfc_unregister_device() beforenci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leakedThus, nfc_unregister_device() is split into two functions so wecan remove rfkill interfaces only before nci_close_device().[0]:DEBUG_LOCKS_WARN_ON(1)WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349Modules linked in:CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1fRSP: 0018:ffffc9000c767680 EFLAGS: 00010046RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa59b39acb9Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007RBP: 00007fa59b408bf7 R08: ---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: t7xx: fix potential skb->frags overflow in RX pathWhen receiving data in the DPMAIF RX path,the t7xx_dpmaif_set_frag_to_skb() function addspage fragments to an skb without checking if the number offragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflowin skb_shinfo(skb)->frags[] array, corrupting adjacent memory andpotentially causing kernel crashes or other undefined behavior.This issue was identified through static code analysis by comparing with asimilar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76:fix array overflow on receiving too many fragments for a packet").The vulnerability could be triggered if the modem firmware sends packetswith excessive fragments. While under normal protocol conditions (MTU 3080bytes, BAT buffer 3584 bytes),a single packet should not require additionalfragments, the kernel should not blindly trust firmware behavior.Malicious, buggy, or compromised firmware could potentially craft packetswith more fragments than the kernel expects.Fix this by adding a bounds check before calling skb_add_rx_frag() toensure nr_frags does not exceed MAX_SKB_FRAGS.The check must be performed before unmapping to avoid a page leakand double DMA unmap during device teardown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: toshiba_haps: Fix memory leaks in add/remove routinestoshiba_haps_add() leaks the haps object allocated by it if it returnsan error after allocating that object successfully.toshiba_haps_remove() does not free the object pointed to bytoshiba_haps before clearing that pointer, so it becomes unreachableallocated memory.Address these memory leaks by using devm_kzalloc() for allocatingthe memory in question.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()When the socket is closed while in TCP_LISTEN a callback is run toflush all outstanding packets, which in turns callsnvmet_tcp_listen_data_ready() with the sk_callback_lock held.So we need to check if we are in TCP_LISTEN before attemptingto get the sk_callback_lock() to avoid a deadlock.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra: Fix a memory leak in tegra_slink_probe()In tegra_slink_probe(), when platform_get_irq() fails, it directlyreturns from the function with an error code, which causes a memory leak.Replace it with a goto label to ensure proper cleanup.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domainsFix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd: fix memory leak in acp3x pdm dma ops
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix oops due to invalid pointer for kfree() in parse_longname()This fixes a kernel oops when reading ceph snapshot directories (.snap),for example by simply running `ls /mnt/my_ceph/.snap`.The variable str is guarded by __free(kfree), but advanced by one forskipping the initial '_' in snapshot names. Thus, kfree() is calledwith an invalid pointer. This patch removes the need for advancing thepointer so kfree() is called with correct memory pointer.Steps to reproduce:1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)2. Add cephfs mount to fstab$ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" >> /etc/fstab3. Reboot the system$ systemctl reboot4. Check if it's really mounted$ mount | grep stuff5. List snapshots (expected 63 snapshots on my system)$ ls /mnt/test/stuff/.snapNow ls hangs forever and the kernel log shows the oops.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: annotate data-races around slave->last_rxslave->last_rx and slave->target_last_arp_rx[...] can be read and writtenlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.syzbot reported:BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validatewrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410...write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline]...value changed: 0x0000000100005365 -> 0x0000000100005366
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmware: Fix hypercall clobbersFedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ...because the QEMU VMware mouse emulation is buggy, and clears the top 32bits of %rdi that the kernel kept a pointer in.The QEMU vmmouse driver saves and restores the register state in a"uint32_t data[6];" and as a result restores the state with the highbits all cleared.RDI originally contained the value of a valid kernel stack address(0xff5eeb3240003e54). After the vmware hypercall it now contains0x40003e54, and we get a page fault as a result when it is dereferenced.The proper fix would be in QEMU, but this works around the issue in thekernel to keep old setups working, when old kernels had not happened tokeep any state in %rdi over the hypercall.In theory this same issue exists for all the hypercalls in the vmmousedriver; in practice it has only been seen with vmware_hypercall3() andvmware_hypercall4(). For now, just mark RDI/RSI as clobbered for thosetwo calls. This should have a minimal effect on code generation overallas it should be rare for the compiler to want to make RDI/RSI liveacross hypercalls.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()In iscsit_dec_conn_usage_count(), the function calls complete() whileholding the conn->conn_usage_lock. As soon as complete() is invoked, thewaiter (such as iscsit_close_connection()) may wake up and proceed to freethe iscsit_conn structure.If the waiter frees the memory before the current thread reachesspin_unlock_bh(), it results in a KASAN slab-use-after-free as the functionattempts to release a lock within the already-freed connection structure.Fix this by releasing the spinlock before calling complete().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: virtio - Add spinlock protection with virtqueue notificationWhen VM boots with one virtio-crypto PCI device and builtin backend,run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head!It seems that the data virtqueue need protection when it is handledfor virtio done notification. If the spinlock protection is addedin virtcrypto_done_task(), openssl benchmark with multiple processesworks well.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix potential NULL pointer dereference in header processingIf siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(),qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data()dereferences qp->rx_fpdu->more_ddp_segs without checking, whichmay lead to a NULL pointer deref. Only check more_ddp_segs whenrx_fpdu is present.KASAN splat:[ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7][ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix memory allocation in nvme_pr_read_keys()nvme_pr_read_keys() takes num_keys from userspace and uses it tocalculate the allocation size for rse via struct_size(). The upperlimit is PR_KEYS_MAX (64K).A malicious or buggy userspace can pass a large num_keys value thatresults in a 4MB allocation attempt at most, causing a warning inthe page allocator when the order exceeds MAX_PAGE_ORDER.To fix this, use kvzalloc() instead of kzalloc().This bug has the same reasoning and fix with the patch below:https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/Warning log:WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272Modules linked in:CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0dRSP: 0018:ffffc90000fcf450 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0Call Trace: alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486 alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557 ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598 __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629 __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245 blkdev_pr_read_keys block/ioctl.c:456 [inline] blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730 blkdev_ioctl+0x299/0x700 block/ioctl.c:786 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583 x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fb893d3108dCode: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108dRDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: secure_seq: add back ports to TS offsetThis reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")tcp_tw_recycle went away in 2017.Zhouyan Deng reported off-path TCP source port leakage viaSYN cookie side-channel that can be fixed in multiple ways.One of them is to bring back TCP ports in TS offset randomization.As a bonus, we perform a single siphash() computationto provide both an ISN and a TS offset.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Compile tested only. Issue found using code review.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Also, decrement i in the devlink_alloc failure path to point to thelast successfully allocated index.Compile tested only. Issue found using code review.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rw: free potentially allocated iovec on cache put failureIf a read/write request goes through io_req_rw_cleanup() and has anallocated iovec attached and fails to put to the rw_cache, then it mayend up with an unaccounted iovec pointer. Have io_rw_recycle() returnwhether it recycled the request or not, and use that to gauge whether tofree a potential iovec or not.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocksAs Paolo said earlier [1]:"Since the blamed commit below, classify can return TC_ACT_CONSUMED whilethe current skb being held by the defragmentation engine. As reported byGangMin Kim, if such packet is that may cause a UaF when the defrag enginelater on tries to tuch again such packet."act_ct was never meant to be used in the egress path, however some usersare attaching it to egress today [2]. Attempting to reach a middleground, we noticed that, while most qdiscs are not handlingTC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, weaddress the issue by only allowing act_ct to bind to clsact/ingressqdiscs and shared blocks. That way it's still possible to attach act_ct toegress (albeit only with clsact).[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/[2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drbd: fix null-pointer dereference on local read errorIn drbd_request_endio(), READ_COMPLETED_WITH_ERROR is passed to__req_mod() with a NULL peer_device: __req_mod(req, what, NULL, &m);The READ_COMPLETED_WITH_ERROR handler then unconditionally passes thisNULL peer_device to drbd_set_out_of_sync(), which dereferences it,causing a null-pointer dereference.Fix this by obtaining the peer_device via first_peer_device(device),matching how drbd_req_destroy() handles the same situation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/sifive-plic: Fix frozen interrupt due to affinity settingPLIC ignores interrupt completion message for disabled interrupt, explainedby the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored.This caused problems in the past, because an interrupt can be disabledwhile still being handled and plic_irq_eoi() had no effect. That was fixedby checking if the interrupt is disabled, and if so enable it, beforesending the completion message. That check is done with irqd_irq_disabled().However, that is not sufficient because the enable bit for the handlinghart can be zero despite irqd_irq_disabled(d) being false. This can happenwhen affinity setting is changed while a hart is still handling theinterrupt.This problem is easily reproducible by dumping a large file to uart (whichgenerates lots of interrupts) and at the same time keep changing the uartinterrupt's affinity setting. The uart port becomes frozen almostinstantaneously.Fix this by checking PLIC's enable bit instead of irqd_irq_disabled().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()Fix a user triggerable leak on the system call failure path.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate data-races around sk->sk_{data_ready,write_space}skmsg (and probably other layers) are changing these pointerswhile other cpus might read them concurrently.Add corresponding READ_ONCE()/WRITE_ONCE() annotationsfor UDP, TCP and AF_UNIX.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix race of nvdimm_bus object when creating nvdimm objectsFound issue during running of cxl-translate.sh unit test. Adding a 3ssleep right before the test seems to make the issue reproduce fairlyconsistently. The cxl_translate module has dependency on cxl_acpi andcauses orphaned nvdimm objects to reprobe after cxl_acpi is removed.The nvdimm_bus object is registered by the cxl_nvb object whencxl_acpi_probe() is called. With the nvdimm_bus object missing,__nd_device_register() will trigger NULL pointer dereference whenaccessing the dev->parent that points to &nvdimm_bus->dev.[ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c[ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025[ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core][ 192.899459] RIP: 0010:kobject_get+0xc/0x90[ 192.924871] Call Trace:[ 192.925959] [ 192.926976] ? pm_runtime_init+0xb9/0xe0[ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm][ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm][ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem][ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core][ 192.943349] really_probe+0xde/0x380This patch also relies on the previous change wheredevm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c insteadof drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called.2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe().3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY.The removal of cxl_nvdimm devices should prevent any orphaned devicesfrom probing once the nvdimm_bus is gone.[ dj: Fixed 0-day reported kdoc issue. ][ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/efi: defer freeing of boot services memoryefi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODEand EFI_BOOT_SERVICES_DATA using memblock_free_late().There are two issue with that: memblock_free_late() should be used formemory allocated with memblock_alloc() while the memory reserved withmemblock_reserve() should be freed with free_reserved_area().More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=yefi_free_boot_services() is called before deferred initialization of thememory map is complete.Benjamin Herrenschmidt reports that this causes a leak of ~140MB ofRAM on EC2 t3a.nano instances which only have 512MB or RAM.If the freed memory resides in the areas that memory map for them isstill uninitialized, they won't be actually freed becausememblock_free_late() calls memblock_free_pages() and the latter skipsuninitialized pages.Using free_reserved_area() at this point is also problematic because__free_page() accesses the buddy of the freed page and that again mightend up in uninitialized part of the memory map.Delaying the entire efi_free_boot_services() could be problematicbecause in addition to freeing boot services memory it updatesefi.memmap without any synchronization and that's undesirable late inboot when there is concurrency.More robust approach is to only defer freeing of the EFI boot servicesmemory.Split efi_free_boot_services() in two. First efi_unmap_boot_services()collects ranges that should be freed into an array thenefi_free_boot_services() later frees them after deferred init is complete.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: Compare MACs in constant timeTo prevent timing attacks, MAC comparisons need to be constant-time.Replace the memcmp() with the correct function, crypto_memneq().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fcloop: Check remoteport port_state before calling done callbackIn nvme_fc_handle_ls_rqst_work, the lsrsp->done callback is only set whenremoteport->port_state is FC_OBJSTATE_ONLINE. Otherwise, thenvme_fc_xmt_ls_rsp's LLDD call to lport->ops->xmt_ls_rsp is expected tofail and the nvme-fc transport layer itself will directly callnvme_fc_xmt_ls_rsp_free instead of relying on LLDD's done callback to freethe lsrsp resources.Update the fcloop_t2h_xmt_ls_rsp routine to check remoteport->port_state.If online, then lsrsp->done callback will free the lsrsp. Else, return-ENODEV to signal the nvme-fc transport to handle freeing lsrsp.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: change XDP RxQ frag_size from DMA write length to xdp.frame_szThe only user of frag_size field in XDP RxQ info isbpf_xdp_frags_increase_tail(). It clearly expects whole buff size insteadof DMA write size. Different assumptions in ice driver configuration leadto negative tailroom.This allows to trigger kernel panic, when usingXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to6912 and the requested offset to a huge value, e.g.XSK_UMEM__MAX_FRAME_SIZE * 100.Due to other quirks of the ZC configuration in ice, panic is not observedin ZC mode, but tailroom growing still fails when it should not.Use fill queue buffer truesize instead of DMA write size in XDP RxQ info.Fix ZC mode too by using the new helper.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: fix divide by zero in the offload pathOffloading ETS requires computing each class' WRR weight: this is done byaveraging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsignedint, the same integer size as the individual DRR quanta, can overflow andeven cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---Fix this using 64-bit integers for 'q_sum' and 'q_psum'.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. Then, if neigh_suppress is enabled and an ICMPv6Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() willdereference ipv6_stub->nd_tbl which is NULL, passing it toneigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() inthe callers. This is in essence disabling NS/NA suppression when IPv6 isdisabled.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPLIn DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDAbuffer cleanup path. It iterates num_bufs times and attempts to unmapentries in the dma array.This leads to two issues:1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations.2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings(trace below is how we noticed this issue).UBSAN: array-index-out-of-bounds indrivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out ofrange for type 'dma_addr_t[18]' (aka 'unsigned long long[18]')Workqueue: gve gve_service_task [gve]Call Trace:dump_stack_lvl+0x33/0xa0__ubsan_handle_out_of_bounds+0xdc/0x110gve_tx_stop_ring_dqo+0x182/0x200 [gve]gve_close+0x1be/0x450 [gve]gve_reset+0x99/0x120 [gve]gve_service_task+0x61/0x100 [gve]process_scheduled_works+0x1e9/0x380Fix this by properly checking for QPL mode and delegating togve_free_tx_qpl_bufs() to reclaim the buffers.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix memory leak in ice_set_ringparam()In ice_set_ringparam, tx_rings and xdp_rings are allocated beforerx_rings. If the allocation of rx_rings fails, the code jumps tothe done label leaking both tx_rings and xdp_rings. Furthermore, ifthe setup of an individual Rx ring fails during the loop, the code jumpsto the free_tx label which releases tx_rings but leaks xdp_rings.Fix this by introducing a free_xdp label and updating the error paths toensure both xdp_rings and tx_rings are properly freed if rx_ringsallocation or setup fails.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=nWhen CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0(success) without actually creating a socket. Callers such asfou_create() then proceed to dereference the uninitialized socketpointer, resulting in a NULL pointer dereference.The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, socallers correctly take their error paths. There is only one caller ofthe vulnerable function and only privileged users can trigger it.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-requests > 0-0 (version in image is 2.25.1-150300.3.18.1).
-
Description: systemd, a system and service manager, (as PID 1) hits an assert and freezes execution when an unprivileged IPC API call is made with spurious data. On version v249 and older the effect is not an assert, but stack overwriting, with the attacker controlled content. From version v250 and newer this is not possible as the safety check causes an assert instead. This IPC call was added in v239, so versions older than that are not affected. Versions 260-rc1, 259.2, 258.5, and 257.11 contain patches. No known workarounds are available.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsystemd0 < 254.27-150600.4.62.1 (version in image is 254.27-150600.4.55.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_expect: use expect->helperUse expect->helper in ctnetlink and /proc to dump the helper name.Using nfct_help() without holding a reference to the master conntrackis unsafe.Use exp->master->helper in ctnetlink path if userspace does not providean explicit helper when creating an expectation to retain the existingbehaviour. The ctnetlink expectation path holds the reference on themaster conntrack and nf_conntrack_expect lock and the nfnetlink gluepath refers to the master ct that is attached to the skb.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: drop logically empty buckets in mtype_delmtype_del() counts empty slots below n->pos in k, but it only drops thebucket when both n->pos and k are zero. This misses buckets whose liveentries have all been removed while n->pos still points past deleted slots.Treat a bucket as empty when all positions below n->pos are unused andrelease it directly instead of shrinking it further.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: skb: fix cross-cache free of KFENCE-allocated skb headSKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2value (e.g. 704 on x86_64) to avoid collisions with generic kmallocbucket sizes. This ensures that skb_kfree_head() can reliably useskb_end_offset to distinguish skb heads allocated fromskb_small_head_cache vs. generic kmalloc caches.However, when KFENCE is enabled, kfence_ksize() returns the exactrequested allocation size instead of the slab bucket size. If a caller(e.g. bpf_test_init) allocates skb head data via kzalloc() and therequested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, thenslab_build_skb() -> ksize() returns that exact value. After subtractingskb_shared_info overhead, skb_end_offset ends up matchingSKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly freethe object to skb_small_head_cache instead of back to the originalkmalloc cache, resulting in a slab cross-cache free: kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1kFix this by always calling kfree(head) in skb_kfree_head(). This keepsthe free path generic and avoids allocator-specific misclassificationfor KFENCE objects.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: jq is a command-line JSON processor. In versions 1.8.1 and below, functions jv_setpath(), jv_getpath(), and delpaths_sorted() in jq's src/jv_aux.c use unbounded recursion whose depth is controlled by the length of a caller-supplied path array, with no depth limit enforced. An attacker can supply a JSON document containing a flat array of ~65,000 integers (~200 KB) that, when used as a path argument by a trusted jq filter, exhausts the C call stack and crashes the process with a segmentation fault (SIGSEGV). This bypass works because the existing MAX_PARSING_DEPTH (10,000) limit only protects the JSON parser, not runtime path operations where arrays can be programmatically constructed to arbitrary lengths. The impact is denial of service (unrecoverable crash) affecting any application or service that processes untrusted JSON input through jq's setpath, getpath, or delpaths builtins. This issue has been addressed in commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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-0 (version in image is 0.8-150600.15.12.1).
-
Description: jq is a command-line JSON processor. In commits after 69785bf77f86e2ea1b4a20ca86775916889e91c9, the _strindices builtin in jq's src/builtin.c passes its arguments directly to jv_string_indexes() without verifying they are strings, and jv_string_indexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like _strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive. Any deployment that evaluates untrusted jq filters against a release build is vulnerable. This issue has been patched in commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.1).
-
Description: jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n^2) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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.34.1).
-
Description: An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers is calculated and truncated into a 32-bit integer. A pointer to partially controlled data can then be written out of bounds.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsqlite3-0 < 3.51.3-150000.3.39.1 (version in image is 3.51.2-150000.3.36.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Fix potential OOB access in audio mixer handlingIn the audio mixer handling code of ctxfi driver, the conf field isused as a kind of loop index, and it's referred in the index callbacks(amixer_index() and sum_index()).As spotted recently by fuzzers, the current code causes OOB access atthose functions.| UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48| index 8 is out of range for type 'unsigned char [8]'After the analysis, the cause was found to be the lack of the proper(re-)initialization of conj field.This patch addresses those OOB accesses by adding the properinitializations of the loop indices.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: A use-after-return vulnerability exists in the `named` server when handling DNS queries signed with SIG(0). Using a specially-crafted DNS request, an attacker may be able to cause an ACL to improperly (mis)match an IP address. In a default-allow ACL (denying only specific IP addresses), this may lead to unauthorized access. Default-deny ACLs should fail-secure.This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1.BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-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.21-150700.3.18.1 (version in image is 9.20.18-150700.3.15.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure no dirty metadata is written back for an fs with errors[BUG]During development of a minor feature (make sure all btrfs_bio::end_io()is called in task context), I noticed a crash in generic/388, wheremetadata writes triggered new works after btrfs_stop_all_workers().It turns out that it can even happen without any code modification, justusing RAID5 for metadata and the same workload from generic/388 is goingto trigger the use-after-free.[CAUSE]If btrfs hits an error, the fs is marked as error, no newtransaction is allowed thus metadata is in a frozen state.But there are some metadata modifications before that error, and they arestill in the btree inode page cache.Since there will be no real transaction commit, all those dirty foliosare just kept as is in the page cache, and they can not be invalidatedby invalidate_inode_pages2() call inside close_ctree(), because they aredirty.And finally after btrfs_stop_all_workers(), we call iput() on btreeinode, which triggers writeback of those dirty metadata.And if the fs is using RAID56 metadata, this will trigger RMW and queuenew works into rmw_workers, which is already stopped, causing warningfrom queue_work() and use-after-free.[FIX]Add a special handling for write_one_eb(), that if the fs is already inan error state, immediately mark the bbio as failure, instead of reallysubmitting them.Then during close_ctree(), iput() will just discard all those dirtytree blocks without really writing them back, thus no more new jobs foralready stopped-and-freed workqueues.The extra discard in write_one_eb() also acts as an extra safenet.E.g. the transaction abort is triggered by some extent/free spacetree corruptions, and since extent/free space tree is already corruptedsome tree blocks may be allocated where they shouldn't be (overwritingexisting tree blocks). In that case writing them back will furthercorrupting the fs.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-urllib3 < 1.25.10-150300.4.24.1 (version in image is 1.25.10-150300.4.21.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: make j1939_session_activate() fail if device is no longer registeredsyzbot is still reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2even after commit 93a27b5891b8 ("can: j1939: add missing calls inNETDEV_UNREGISTER notification handler") was added. A debug printk() patchfound that j1939_session_activate() can succeed even afterj1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER)has completed.Since j1939_cancel_active_session() is processed with the session list lockheld, checking ndev->reg_state in j1939_session_activate() with the sessionlist lock held can reliably close the race window.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: fix a double free in snd_ac97_controller_register()If ac97_add_adapter() fails, put_device() is the correct way to dropthe device reference. kfree() is not required.Add kfree() if idr_alloc() fails and in ac97_adapter_release() to dothe cleanup.Found by code review.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: suspend array while updating raid_disks via sysfsIn raid1_reshape(), freeze_array() is called before modifying the r1biomemory pool (conf->r1bio_pool) and conf->raid_disks, andunfreeze_array() is called after the update is completed.However, freeze_array() only waits until nr_sync_pending and(nr_pending - nr_queued) of all buckets reaches zero. When an I/O erroroccurs, nr_queued is increased and the corresponding r1bio is queued toeither retry_list or bio_end_io_list. As a result, freeze_array() mayunblock before these r1bios are released.This can lead to a situation where conf->raid_disks and the mempool havealready been updated while queued r1bios, allocated with the oldraid_disks value, are later released. Consequently, free_r1bio() mayaccess memory out of bounds in put_all_bios() and release r1bios of thewrong size to the new mempool, potentially causing issues with themempool as well.Since only normal I/O might increase nr_queued while an I/O error occurs,suspending the array avoids this issue.Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspendsthe array. Therefore, we suspend the array when updating raid_disksvia sysfs to avoid this issue too.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.2.0110-150500.20.43.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix memory leak in skb_segment_list for GRO packetsWhen skb_segment_list() is called during packet forwarding, it handlespackets that were aggregated by the GRO engine.Historically, the segmentation logic in skb_segment_list assumes thatindividual segments are split from a parent SKB and may need to carrytheir own socket memory accounting. Accordingly, the code transferstruesize from the parent to the newly created segments.Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), thistruesize subtraction in skb_segment_list() was valid because fragmentsstill carry a reference to the original socket.However, commit ed4cccef64c1 ("gro: fix ownership transfer") changedthis behavior by ensuring that fraglist entries are explicitlyorphaned (skb->sk = NULL) to prevent illegal orphaning later in thestack. This change meant that the entire socket memory charge remainedwith the head SKB, but the corresponding accounting logic inskb_segment_list() was never updated.As a result, the current code unconditionally adds each fragment'struesize to delta_truesize and subtracts it from the parent SKB. Sincethe fragments are no longer charged to the socket, this subtractionresults in an effective under-count of memory when the head is freed.This causes sk_wmem_alloc to remain non-zero, preventing socketdestruction and leading to a persistent memory leak.The leak can be observed via KMEMLEAK when tearing down the networkingenvironment:unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLISTpackets constructed by GRO, the truesize adjustment is removed.The call to skb_release_head_state() must be preserved. As documented incommit cf673ed0e057 ("net: fix fraglist segmentation reference countleak"), it is still required to correctly drop references to SKBextensions that may be overwritten during __copy_skb_header().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Sanitize payload size to prevent member overflowIn qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_sizereported by firmware is used to calculate the copy length intoitem->iocb. However, the iocb member is defined as a fixed-size 64-bytearray within struct purex_item.If the reported frame_size exceeds 64 bytes, subsequent memcpy calls willoverflow the iocb member boundary. While extra memory might be allocated,this cross-member write is unsafe and triggers warnings underCONFIG_FORTIFY_SOURCE.Fix this by capping total_bytes to the size of the iocb member (64 bytes)before allocation and copying. This ensures all copies remain within thebounds of the destination structure member.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix use-after-free due to enslave fail after slave array updateFix a use-after-free which happens due to enslave failure after the newslave has been added to the array. Since the new slave can be used for Tximmediately, we can use it after it has been freed by the enslave errorcleanup path which frees the allocated slave memory. Slave update array issupposed to be called last when further enslave failures are not expected.Move it after xdp setup to avoid any problems.It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummyThen run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? __pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix use-after-free in driver_override_show()The driver_override_show() function reads the driver_override stringwithout holding the device_lock. However, driver_override_store() usesdriver_set_override(), which modifies and frees the string while holdingthe device_lock.This can result in a concurrent use-after-free if the string is freedby the store function while being read by the show function.Fix this by holding the device_lock around the read operation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: lec: fix null-ptr-deref in lec_arp_clear_vccssyzkaller reported a null-ptr-deref in lec_arp_clear_vccs().This issue can be easily reproduced using the syzkaller reproducer.In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared bymultiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc).When the underlying VCC is closed, lec_vcc_close() iterates over allARP entries and calls lec_arp_clear_vccs() for each matched entry.For example, when lec_vcc_close() iterates through the hlists inpriv->lec_arp_empty_ones or other ARP tables:1. In the first iteration, for the first matched ARP entry sharing the VCC,lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back)and sets vcc->user_back to NULL.2. In the second iteration, for the next matched ARP entry sharing the sameVCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv fromvcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference itvia `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash.Fix this by adding a null check for vpriv before dereferencingit. If vpriv is already NULL, it means the VCC has been clearedby a previous call, so we can safely skip the cleanup and justclear the entry's vcc/recv_vcc pointers.The entire cleanup block (including vcc_release_async()) is placed insidethe vpriv guard because a NULL vpriv indicates the VCC has already beenfully released by a prior iteration - repeating the teardown wouldredundantly set flags and trigger callbacks on an already-closing socket.The Fixes tag points to the initial commit because the entry->vcc path hasbeen vulnerable since the original code. The entry->recv_vcc path was lateradded by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back")with the same pattern, and both paths are fixed here.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Issue summary: During processing of a crafted CMS EnvelopedData messagewith KeyAgreeRecipientInfo a NULL pointer dereference can happen.Impact summary: Applications that process attacker-controlled CMS data maycrash before authentication or cryptographic operations occur resulting inDenial of Service.When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo isprocessed, the optional parameters field of KeyEncryptionAlgorithmIdentifieris examined without checking for its presence. This results in a NULLpointer dereference if the field is missing.Applications and services that call CMS_decrypt() on untrusted input(e.g., S/MIME processing or CMS-based protocols) are vulnerable.The FIPS modules in 3.6, 3.5, 3.4, 3.3 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.16.1 (version in image is 1.1.1w-150700.11.11.1).
-
Description: Vim is an open source, command line text editor. From 9.1.0011 to before 9.2.0137, Vim's NFA regex compiler, when encountering a collection containing a combining character as the endpoint of a character range (e.g. [0-0\u05bb]), incorrectly emits the composing bytes of that character as separate NFA states. This corrupts the NFA postfix stack, resulting in NFA_START_COLL having a NULL out1 pointer. When nfa_max_width() subsequently traverses the compiled NFA to estimate match width for the look-behind assertion, it dereferences state->out1->out without a NULL check, causing a segmentation fault. This vulnerability is fixed in 9.2.0137.
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.0110-150500.20.43.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0202, a command injection vulnerability exists in Vim's glob() function on Unix-like systems. By including a newline character (\n) in a pattern passed to glob(), an attacker may be able to execute arbitrary shell commands. This vulnerability depends on the user's 'shell' setting. This issue has been patched in version 9.2.0202.
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.0110-150500.20.43.1).
-
Description: jq is a command-line JSON processor. Commits before 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b contain a vulnerability where CLI input parsing allows validation bypass via embedded NUL bytes. When reading JSON from files or stdin, jq uses strlen() to determine buffer length instead of the actual byte count from fgets(), causing it to truncate input at the first NUL byte and parse only the preceding prefix. This enables an attacker to craft input with a benign JSON prefix before a NUL byte followed by malicious trailing data, where jq validates only the prefix as valid JSON while silently discarding the suffix. Workflows relying on jq to validate untrusted JSON before forwarding it to downstream consumers are susceptible to parser differential attacks, as those consumers may process the full input including the malicious trailing bytes. This issue has been patched by commit 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq > 0-0 (version in image is 1.6-150000.3.12.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftp_extensions_get_name/sftp_extensions_get_data of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config < 0.9.8-150600.11.12.1 (version in image is 0.9.8-150600.11.9.1).
-
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:w1: therm: Fix off-by-one buffer overflow in alarms_storeThe sysfs buffer passed to alarms_store() is allocated with 'size + 1'bytes and a NUL terminator is appended. However, the 'size' argumentdoes not account for this extra byte. The original code then allocated'size' bytes and used strcpy() to copy 'buf', which always writes onebyte past the allocated buffer since strcpy() copies until the NULterminator at index 'size'.Fix this by parsing the 'buf' parameter directly using simple_strtoll()without allocating any intermediate memory or string copying. Thisremoves the overflow while simplifying the code.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix devlink reload call traceCommit 4da71a77fc3b ("ice: read internal temperature sensor") introducedinternal temperature sensor reading via HWMON. ice_hwmon_init() was addedto ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As aresult if devlink reload is used to reinit the device and then the driveris removed, a call trace can occur.BUG: unable to handle page fault for address: ffffffffc0fd4b5dCall Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60The call trace repeats approximately every 10 minutes when systemmonitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfsattributes that reference freed module memory.The sequence is:1. Driver load, ice_hwmon_init() gets called from ice_init_feature()2. Devlink reload down, flow does not call ice_remove()3. Devlink reload up, ice_hwmon_init() gets called from ice_init_feature() resulting in a second instance4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the first hwmon instance orphaned with dangling pointerFix this by moving ice_hwmon_exit() from ice_remove() toice_deinit_features() to ensure proper cleanup symmetry withice_hwmon_init().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()`i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of datainto `ihid->rawbuf`.The former can come from the userspace in the hidraw driver and is onlybounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set`max_buffer_size` field of `struct hid_ll_driver` which we do not).The latter has size determined at runtime by the maximum size ofdifferent report types you could receive on any particular device andcan be a much smaller value.Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`.The impact is low since access to hidraw devices requires root.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.3.12.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: CR/LF bytes were not rejected by HTTP client proxy tunnel headers or host.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't log conflicting inode if it's a dir moved in the current transactionWe can't log a conflicting inode if it's a directory and it was movedfrom one parent directory to another parent directory in the currenttransaction, as this can result an attempt to have a directory withtwo hard links during log replay, one for the old parent directory andanother for the new parent directory.The following scenario triggers that issue:1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory;2) We move "dir1" to some other directory;3) We create a file with the name "dir1" in directory inode A;4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1";5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name();6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory);7) We have a power failure;8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1".As a result after log replay finishes when we trigger writeback of thesubvolume tree's extent buffers, the tree check will detect that we havea directory a hard link count of 2 and we get a mount failure.The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [ 3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [ 3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [ 3845.737816] location key (257 1 0) type 2 [---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: fix use-after-free on probe deferralThe driver is dropping the references taken to the larb devices duringprobe after successful lookup as well as on errors. This canpotentially lead to a use-after-free in case a larb device has not yetbeen bound to its driver so that the iommu driver probe defers.Fix this by keeping the references as expected while the iommu driver isbound.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: restore destructor on submit failurehandshake_req_submit() replaces sk->sk_destruct but never restores it whensubmission fails before the request is hashed. handshake_sk_destruct() thenreturns early and the original destructor never runs, leaking the socket.Restore sk_destruct on the error path.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock in wait_current_trans() due to ignored transaction typeWhen wait_current_trans() is called during start_transaction(), itcurrently waits for a blocked transaction without considering whetherthe given transaction type actually needs to wait for that particulartransaction state. The btrfs_blocked_trans_types[] array already defineswhich transaction types should wait for which transaction states, butthis check was missing in wait_current_trans().This can lead to a deadlock scenario involving two transactions andpending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction BThis can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!)Task bstore_kv_sync in btrfs_commit_transaction waiting for orderedextents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30Fix this by passing the transaction type to wait_current_trans() andchecking btrfs_blocked_trans_types[cur_trans->state] against the giventype before deciding to wait. This ensures that transaction types whichare allowed to join during certain blocked states will not unnecessarilywait and cause deadlocks.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not free data reservation in fallback from inline due to -ENOSPCIf we fail to create an inline extent due to -ENOSPC, we will attempt togo through the normal COW path, reserve an extent, create an orderedextent, etc. However we were always freeing the reserved qgroup data,which is wrong since we will use data. Fix this by freeing the reservedqgroup data in __cow_file_range_inline() only if we are not doing thefallback (ret is <= 0).
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()The for_each_available_child_of_node() calls of_node_put() torelease child_np in each success loop. After breaking from theloop with the child_np has been released, the code will jump tothe put_child label and will call the of_node_put() again if thedevm_request_threaded_irq() fails. These cause a double free bug.Fix by returning directly to avoid the duplicate of_node_put().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix a deadlock when returning a delegation during open()Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935The issue is that the delegreturn is being asked to wait for a layoutreturn that cannot complete because a state recovery was initiated. Thestate recovery cannot complete until the open() finishes processing thedelegations it was given.The solution is to propagate the existing flags that indicate anon-blocking call to the function pnfs_roc(), so that it knows not towait in this situation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a deadlock involving nfs_release_folio()Wang Zhaolong reports a deadlock involving NFSv4.1 state recoverywaiting on kthreadd, which is attempting to reclaim memory by callingnfs_release_folio(). The latter cannot make progress due to staterecovery being needed.It seems that the only safe thing to do here is to kick off a writebackof the folio, without waiting for completion, or else kicking off anasynchronous commit.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), theURBs for USB-in transfers are allocated, added to the dev->rx_submittedanchor and submitted. In the complete callbackkvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inkvaser_usb_remove_interfaces() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in thekvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix potential underflow in virtio_transport_get_credit()The credit calculation in virtio_transport_get_credit() uses unsignedarithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);If the peer shrinks its advertised buffer (peer_buf_alloc) while bytesare in flight, the subtraction can underflow and produce a largepositive value, potentially allowing more data to be queued than thepeer can handle.Reuse virtio_transport_has_space() which already handles this case andadd a comment to make it clear why we are doing that.[Stefano: use virtio_transport_has_space() instead of duplicating the code][Stefano: tweak the commit message]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_agThis is more of a preventive patch to make the code more consistent andto prevent possible exploits that employ child qlen manipulations on qfq.use cl_is_active instead of relying on the child qdisc's qlen to determineclass activation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Wake up the error handler when final completions race against each otherThe fragile ordering between marking commands completed or failed sothat the error handler only wakes when the last running commandcompletes or times out has race conditions. These race conditions cancause the SCSI layer to fail to wake the error handler, leaving I/Othrough the SCSI host stuck as the error state cannot advance.First, there is an memory ordering issue within scsi_dec_host_busy().The write which clears SCMD_STATE_INFLIGHT may be reordered with readscounting in scsi_host_busy(). While the local CPU will see its ownwrite, reordering can allow other CPUs in scsi_dec_host_busy() orscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU tosee a host busy equal to the host_failed count.This race condition can be prevented with a memory barrier on the errorpath to force the write to be visible before counting host busycommands.Second, there is a general ordering issue with scsi_eh_inc_host_failed(). Bycounting busy commands before incrementing host_failed, it can race with afinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() doesnot see host_failed incremented but scsi_eh_inc_host_failed() counts busycommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),resulting in neither waking the error handler task.This needs the call to scsi_host_busy() to be moved after host_failed isincremented to close the race condition.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: fix dma_free_coherent() pointerdma_alloc_coherent() allocates a DMA mapped buffer and stores theaddresses in XXX_unaligned fields. Those should be reused when freeingthe buffer rather than the aligned addresses.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: fix dma_free_coherent() pointerdma_alloc_coherent() allocates a DMA mapped buffer and stores theaddresses in XXX_unaligned fields. Those should be reused when freeingthe buffer rather than the aligned addresses.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_workhci_uart_set_proto() sets HCI_UART_PROTO_INIT before callinghci_uart_register_dev(), which calls proto->open() to initializehu->priv. However, if a TTY write wakeup occurs during this window,hci_uart_tx_wakeup() may schedule write_work before hu->priv isinitialized, leading to a NULL pointer dereference inhci_uart_write_work() when proto->dequeue() accesses hu->priv.The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!)Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open()succeeds, ensuring hu->priv is initialized before any work can bescheduled.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().syzbot reported various memory leaks related to NFC, structnfc_llcp_sock, sk_buff, nfc_dev, etc. [0]The leading log hinted that nfc_llcp_send_ui_frame() failedto allocate skb due to sock_error(sk) being -ENXIO.ENXIO is set by nfc_llcp_socket_release() when structnfc_llcp_local is destroyed by local_cleanup().The problem is that there is no synchronisation betweennfc_llcp_send_ui_frame() and local_cleanup(), and skbcould be put into local->tx_queue after it was purged inlocal_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.'local_cleanup() is called for struct nfc_llcp_local onlyafter nfc_llcp_remove_local() unlinks it from llcp_devices.If we hold local->tx_queue.lock then, we can synchronisethe thread and nfc_llcp_send_ui_frame().Let's do that and check list_empty(&local->list) beforequeuing skb to local->tx_queue in nfc_llcp_send_ui_frame().[0]:[ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)[ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)BUG: memory leakunreferenced object 0xffff8881272f6800 (size 1024): comm "syz.0.17", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fBUG: memory leakunreferenced object 0xffff88810fbd9800 (size 240): comm "syz.0.17", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Don't clobber irqfd routing type when deassigning irqfdWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ'srouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, tohandle a concurrent routing update, verify that the irqfd is still activebefore consuming the routing information. As evidenced by the x86 andarm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),clobbering the entry type without notifying arch code is surprising anderror prone.As a bonus, checking that the irqfd is active provides a convenientlocation for documenting _why_ KVM must not consume the routing entry foran irqfd that is in the process of being deassigned: once the irqfd isdeleted from the list (which happens *before* the eventfd is detached), itwill no longer receive updates via kvm_irq_routing_update(), and so KVMcould deliver an event using stale routing information (relative toKVM_SET_GSI_ROUTING returning to userspace).As an even better bonus, explicitly checking for the irqfd being activefixes a similar bug to the one the clobbering is trying to prevent: if anirqfd is deactivated, and then its routing is changed,kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()(because the irqfd isn't in the list). And so if the irqfd is in bypassmode, IRQs will continue to be posted using the old routing information.As for kvm_arch_irq_bypass_del_producer(), clobbering the routing typeresults in KVM incorrectly keeping the IRQ in bypass mode, which isespecially problematic on AMD as KVM tracks IRQs that are being posted toa vCPU in a list whose lifetime is tied to the irqfd.Without the help of KASAN to detect use-after-free, the most commonsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due tothe memory for irqfd structure being re-allocated and zeroed, resultingin irqfd->irq_bypass_data being NULL when read byavic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]---If AVIC is inhibited when the irfd is deassigned, the bug will manifest aslist corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa---truncated---
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Protect curr_xfer check in IRQ handlerNow that all other accesses to curr_xfer are done under the lock,protect the curr_xfer NULL check in tegra_qspi_isr_thread() with thespinlock. Without this protection, the following race can occur: CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->curr_xfer) // sees non-NULL spin_lock() tqspi->curr_xfer = NULL spin_unlock() handle_*_xfer() spin_lock() t = tqspi->curr_xfer // NULL! ... t->len ... // NULL dereference!With this patch, all curr_xfer accesses are now properly synchronized.Although all accesses to curr_xfer are done under the lock, integra_qspi_isr_thread() it checks for NULL, releases the lock andreacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().There is a potential for an update in between, which could cause a NULLpointer dereference.To handle this, add a NULL check inside the handlers after acquiringthe lock. This ensures that if the timeout path has already clearedcurr_xfer, the handler will safely return without dereferencing theNULL pointer.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix PTP NULL pointer dereference during VSI rebuildFix race condition where PTP periodic work runs while VSI is beingrebuilt, accessing NULL vsi->rx_rings.The sequence was:1. ice_ptp_prepare_for_reset() cancels PTP work2. ice_ptp_rebuild() immediately queues PTP work3. VSI rebuild happens AFTER ice_ptp_rebuild()4. PTP work runs and accesses NULL vsi->rx_ringsFix: Keep PTP work cancelled during rebuild, only queue it afterVSI rebuild completes in ice_rebuild().Added ice_ptp_queue_work() helper function to encapsulate the logicfor queuing PTP work, ensuring it's only queued when PTP is supportedand the state is ICE_PTP_READY.Error log:[ 121.392544] ice 0000:60:00.1: PTP reset successful[ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 121.392712] #PF: supervisor read access in kernel mode[ 121.392720] #PF: error_code(0x0000) - not-present page[ 121.392727] PGD 0[ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI[ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)[ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC[ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice][ 121.393042] Call Trace:[ 121.393047] [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice][ 121.393202] kthread_worker_fn+0xa2/0x260[ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice][ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10[ 121.393371] kthread+0x10d/0x230[ 121.393382] ? __pfx_kthread+0x10/0x10[ 121.393393] ret_from_fork+0x273/0x2b0[ 121.393407] ? __pfx_kthread+0x10/0x10[ 121.393417] ret_from_fork_asm+0x1a/0x30[ 121.393432]
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add proper RCU protection to /proc/net/ptypeYin Fengwei reported an RCU stall in ptype_seq_show() and provideda patch.Real issue is that ptype_seq_next() and ptype_seq_show() violateRCU rules.ptype_seq_show() runs under rcu_read_lock(), and reads pt->devto get device name without any barrier.At the same time, concurrent writers can remove a packet_type structure(which is correctly freed after an RCU grace period) and clear pt->devwithout an RCU grace period.Define ptype_iter_state to carry a dev pointer along seq_net_private:struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch};We need to record the device pointer in ptype_get_idx() andptype_seq_next() so that ptype_seq_show() is safe againstconcurrent pt->dev changes.We also need to add full RCU protection in ptype_seq_next().(Missing READ_ONCE() when reading list.next values)Many thanks to Dong Chenchen for providing a repro.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boostingRunning stress-ng --schedpolicy 0 on an RT kernel on a big machinemight lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ...The problem is that when a SCHED_DEADLINE task (lock holder) ischanged to a lower priority class via sched_setscheduler(), it mayfail to properly inherit the parameters of potential DEADLINE donorsif it didn't already inherit them in the past (shorter deadline thandonor's at that time). This might lead to bandwidth accountingcorruption, as enqueue_task_dl() won't recognize the lock holder asboosted.The scenario occurs when:1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline)2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happenFix the issue by introducing __setscheduler_dl_pi(), which detects whena DEADLINE (proper or boosted) task gets setscheduled to a lowerpriority class. In case, the function makes the task inherit DEADLINEparameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag toensure proper bandwidth accounting during the next enqueue operation.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Purge async_hold in tls_decrypt_async_wait()The async_hold queue pins encrypted input skbs whilethe AEAD engine references their scatterlist data. Oncetls_decrypt_async_wait() returns, every AEAD operationhas completed and the engine no longer references thoseskbs, so they can be freed unconditionally.A subsequent patch adds batch async decryption totls_sw_read_sock(), introducing a new call site thatmust drain pending AEAD operations and release heldskbs. Move __skb_queue_purge(&ctx->async_hold) intotls_decrypt_async_wait() so the purge is centralizedand every caller -- recvmsg's drain path, the -EBUSYfallback in tls_do_decryption(), and the new read_sockbatch path -- releases held skbs on synchronizationwithout each site managing the purge independently.This fixes a leak when tls_strp_msg_hold() fails part-way through,after having added some cloned skbs to the async_holdqueue. tls_decrypt_sg() will then call tls_decrypt_async_wait() toprocess all pending decrypts, and drop back to synchronous mode, buttls_sw_recvmsg() only flushes the async_hold queue when one record hasbeen processed in "fully-async" mode, which may not be the case here.[pabeni@redhat.com: added leak comment]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/poll: fix multishot recv missing EOF on wakeup raceWhen a socket send and shutdown() happen back-to-back, both firewake-ups before the receiver's task_work has a chance to run. The firstwake gets poll ownership (poll_refs=1), and the second bumps it to 2.When io_poll_check_events() runs, it calls io_poll_issue() which does arecv that reads the data and returns IOU_RETRY. The loop then drains allaccumulated refs (atomic_sub_return(2) -> 0) and exits, even though onlythe first event was consumed. Since the shutdown is a persistent statechange, no further wakeups will happen, and the multishot recv can hangforever.Check specifically for HUP in the poll loop, and ensure that anotherloop is done to check for status if more than a single poll activationis pending. This ensures we don't lose the shutdown event.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-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.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm/bus: Fix potential use after free in asynchronous initializationDingisoul with KASAN reports a use after free if device_add() fails innd_async_device_register().Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent whilescheduling async init") correctly added a reference on the parent deviceto be held until asynchronous initialization was complete. However, ifdevice_add() results in an allocation failure the ref count of thedevice drops to 0 prior to the parent pointer being accessed. Thusresulting in use after free.The bug bot AI correctly identified the fix. Save a reference to theparent pointer to be used to drop the parent reference regardless of theoutcome of device_add().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Calling gethostbyaddr or gethostbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend in the GNU C Library version 2.34 to version 2.43 could, with a crafted response from the configured DNS server, result in a violation of the DNS specification that causes the application to treat a non-answer section of the DNS response as a valid answer.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc < 2.38-150600.14.46.1 (version in image is 2.38-150600.14.43.1).
-
Description: Calling gethostbyaddr or gethostbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend in the GNU C library version 2.34 to version 2.43 could result in an invalid DNS hostname being returned to the caller in violation of the DNS specification.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc < 2.38-150600.14.46.1 (version in image is 2.38-150600.14.43.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject new transactions if the fs is fully read-only[BUG]There is a bug report where a heavily fuzzed fs is mounted with allrescue mount options, which leads to the following warnings duringunmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Since rescue mount options will mark the full fs read-only, there shouldbe no new transaction triggered.But during unmount we will evict all inodes, which can trigger a newtransaction, and triggers warnings on a heavily corrupted fs.[CAUSE]Btrfs allows new transaction even on a read-only fs, this is to allowlog replay happen even on read-only mounts, just like what ext4/xfs do.However with rescue mount options, the fs is fully read-only and cannotbe remounted read-write, thus in that case we should also reject any newtransactions.[FIX]If we find the fs has rescue mount options, we should treat the fs aserror, so that no new transaction can be started.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
- sle-module-containers-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd-ctr > 0-0 (version in image is 1.7.29-150000.128.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()The ethtool tsconfig Netlink path can trigger a null pointerdereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower()results in generic_hwtstamp_ioctl_lower() being called withkernel_cfg->ifr as NULL.The generic_hwtstamp_ioctl_lower() function does not expecta NULL ifr and dereferences it, leading to a system crash.Fix this by adding a NULL check for kernel_cfg->ifr ingeneric_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libncurses6 > 0-0 (version in image is 6.1-150000.5.30.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detectionThe st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULLevent_spec field, indicating support for IIO events. However, eventdetection is not supported for all sensors, and if userspace tries toconfigure accelerometer wakeup events on a sensor device that does notsupport them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULLpointer when trying to write to the wakeup register.Define an additional struct iio_chan_spec array whose members have a NULLevent_spec field, and use this array instead of st_lsm6dsx_acc_channels forsensors without event detection capability.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driverat91_adc_interrupt can call at91_adc_touch_data_handler functionto start the work by schedule_work(&st->touch_st.workq).If we remove the module which will call at91_adc_remove tomake cleanup, it will free indio_dev through iio_device_unregister butquite a bit later. While the work mentioned above will be used. Thesequence of operations that may lead to a UAF bug is as follows:CPU0 CPU1 | at91_adc_workq_handlerat91_adc_remove |iio_device_unregister(indio_dev) |//free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_devFix it by ensuring that the work is canceled before proceeding withthe cleanup in at91_adc_remove.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Free sp in error path to fix system crashSystem crash seen during load/unload test in a loop,[61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X.[61110.467494] =============================================================================[61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown()[61110.467501] -----------------------------------------------------------------------------[61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff)[61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1[61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023[61110.467515] Call Trace:[61110.467516] [61110.467519] dump_stack_lvl+0x34/0x48[61110.467526] slab_err.cold+0x53/0x67[61110.467534] __kmem_cache_shutdown+0x16e/0x320[61110.467540] kmem_cache_destroy+0x51/0x160[61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx][61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280[61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0[61110.467616] ? do_syscall_64+0x5c/0x90[61110.467619] ? exc_page_fault+0x62/0x150[61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd[61110.467626] [61110.467627] Disabling lock debugging due to kernel taint[61110.467635] Object 0x0000000026f7e6e6 @offset=16000[61110.467639] ------------[ cut here ]------------[61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx][61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160[61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1[61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023[61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160[61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89[61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282[61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027[61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0[61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7[61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000[61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000[61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0[61110.467736] PKRU: 55555554[61110.467737] Call Trace:[61110.467738] [61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx][61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280Free sp in the error path to fix the crash.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Avoid creating sub-groups asynchronouslyThe asynchronous creation of sub-groups by a delayed work could lead to aNULL pointer dereference when the driver directory is removed before thework completes.The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0Fix this issue by using configfs_add_default_group() API which does nothave the deadlock problem as configfs_register_group() and does not requirethe delayed work handler.[mani: slightly reworded the description and added stable list]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Delay module unload while fabric scan in progressSystem crash seen during load/unload test in a loop.[105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086[105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0[105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000[105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000[105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0[105954.384928] PKRU: 55555554[105954.384929] Call Trace:[105954.384931] [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx][105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx][105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx][105954.384999] ? __wake_up_common+0x80/0x190[105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx][105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx][105954.385040] ? __handle_irq_event_percpu+0x3d/0x190[105954.385044] ? handle_irq_event+0x58/0xb0[105954.385046] ? handle_edge_irq+0x93/0x240[105954.385050] ? __common_interrupt+0x41/0xa0[105954.385055] ? common_interrupt+0x3e/0xa0[105954.385060] ? asm_common_interrupt+0x22/0x40The root cause of this was that there was a free (dma_free_attrs) in theinterrupt context. There was a device discovery/fabric scan inprogress. A module unload was issued which set the UNLOADING flag. Aspart of the discovery, after receiving an interrupt a work queue wasscheduled (which involved a work to be queued). Since the UNLOADINGflag is set, the work item was not allocated and the mapped memory hadto be freed. The free occurred in interrupt context leading to systemcrash. Delay the driver unload until the fabric scan is complete toavoid the crash.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leakIn gs_can_open(), the URBs for USB-in transfers are allocated, added to theparent->rx_submitted anchor and submitted. In the complete callbackgs_usb_receive_bulk_callback(), the URB is processed and resubmitted. Ings_can_close() the URBs are freed by callingusb_kill_anchored_urbs(parent->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in gs_can_close().Fix the memory leak by anchoring the URB in thegs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ife: avoid possible NULL dereftcf_ife_encode() must make sure ife_encode() does not return NULL.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: spi-sprd-adi: Fix double free in probe error pathThe driver currently uses spi_alloc_host() to allocate the controllerbut registers it using devm_spi_register_controller().If devm_register_restart_handler() fails, the code jumps to theput_ctlr label and calls spi_controller_put(). However, since thecontroller was registered via a devm function, the device core willautomatically call spi_controller_put() again when the probe fails.This results in a double-free of the spi_controller structure.Fix this by switching to devm_spi_alloc_host() and removing themanual spi_controller_put() call.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_listWhen the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() isset to false, the driver may request the PMAC_ID from the firmware of thenetwork card, and this function will store that PMAC_ID at the providedaddress pmac_id. This is the contract of this function.However, there is a location within the driver where bothpmac_id_valid == false and pmac_id == NULL are being passed. This couldresult in dereferencing a NULL pointer.To resolve this issue, it is necessary to pass the address of a stubvariable to the function.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers areallocated, added to the priv->rx_submitted anchor and submitted. In thecomplete callback usb_8dev_read_bulk_callback(), the URBs are processed andresubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed bycalling usb_kill_anchored_urbs(&priv->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in theusb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_removeOn APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 andih2 interrupt ring buffers are not initialized. This is by design, asthese secondary IH rings are only available on discrete GPUs. Seevega10_ih_sw_init() which explicitly skips ih1/ih2 initialization whenAMD_IS_APU is set.However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 toget the timestamp of the last interrupt entry. When retry faults areenabled on APUs (noretry=0), this function is called from the SVM pagefault recovery path, resulting in a NULL pointer dereference whenamdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu]This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HWIP 9.3.0 from noretry=1") which changed the default for Renoir APU fromnoretry=1 to noretry=0, enabling retry fault handling and thusexercising the buggy code path.Fix this by adding a check for ih1.ring_size before attempting to useit. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu:Rework retry fault removal"). This is needed if the hardware doesn'tsupport secondary HW IH rings.v2: additional updates (Alex)(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix NULL pointer dereference in ice_vsi_set_napi_queuesAdd NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashesduring resume from suspend when rings[q_idx]->q_vector is NULL.Tested adaptor:60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]SR-IOV state: both disabled and enabled can reproduce this issue.kernel version: v6.18Reproduce steps:Boot up and execute suspend like systemctl suspend or rtcwake.Log:<1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040<1>[ 231.444052] #PF: supervisor read access in kernel mode<1>[ 231.444484] #PF: error_code(0x0000) - not-present page<6>[ 231.444913] PGD 0 P4D 0<4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI<4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170<4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89<4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202<4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010<4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000<4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000<4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000<4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000<4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0<4>[ 231.451629] PKRU: 55555554<4>[ 231.452076] Call Trace:<4>[ 231.452549] <4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]<4>[ 231.453482] ice_resume+0xfd/0x220 [ice]<4>[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10<4>[ 231.454425] pci_pm_resume+0x8c/0x140<4>[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10<4>[ 231.455347] dpm_run_callback+0x5f/0x160<4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170<4>[ 231.456244] device_resume+0x177/0x270<4>[ 231.456708] dpm_resume+0x209/0x2f0<4>[ 231.457151] dpm_resume_end+0x15/0x30<4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0<4>[ 231.458054] enter_state+0x10e/0x570Add defensive checks for both the ring pointer and its q_vectorbefore dereferencing, allowing the system to resume successfully even whenq_vectors are unmapped.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/imx/tve: fix probe device leakMake sure to drop the reference taken to the DDC device during probe onprobe failure (e.g. probe deferral) and on driver unbind.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: TC, delete flows only for existing peersWhen deleting TC steering flows, iterate only over actual devcompeers instead of assuming all possible ports exist. This avoidstouching non-existent peers and ensures cleanup is limited todevices the driver is currently connected to. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress] __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320 ? __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1ef/0x230 ? copy_msghdr_from_user+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Disable MMIO access during SMU Mode 1 resetDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomestemporarily inaccessible via PCIe. Any attempt to access MMIO registersduring this window (e.g., from interrupt handlers or other driver threads)can result in uncompleted PCIe transactions, leading to NMI panics orsystem hangs.To prevent this, set the `no_hw_access` flag to true immediately aftertriggering the reset. This signals other driver components to skipregister accesses while the device is offline.A memory barrier `smp_mb()` is added to ensure the flag update isglobally visible to all cores before the driver enters the sleep/waitstate.(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix recursive locking in __configfs_open_file()In flush_write_buffer, &p->frag_sem is acquired and then the loaded storefunction is called, which, here, is target_core_item_dbroot_store(). Thisfunction called filp_open(), following which these functions were called(in reverse order), according to the call trace: down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_itertarget_core_item_dbroot_store() tries to validate the new file path bytrying to open the file path provided to it; however, in this case, the bugreport shows:db_root: not a directory: /sys/kernel/config/target/dbrootindicating that the same configfs file was tried to be opened, on which itis currently working on. Thus, it is trying to acquire frag_sem semaphoreof the same file of which it already holds the semaphore obtained inflush_write_buffer(), leading to acquiring the semaphore in a nested mannerand a possibility of recursive locking.Fix this by modifying target_core_item_dbroot_store() to use kern_path()instead of filp_open() to avoid opening the file using filesystem-specificfunction __configfs_open_file(), and further modifying it to make this fixcompatible.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loadedbond_option_mode_set() already rejects mode changes that would make aloaded XDP program incompatible via bond_xdp_check(). However,bond_option_xmit_hash_policy_set() has no such guard.For 802.3ad and balance-xor modes, bond_xdp_check() returns false whenxmit_hash_policy is vlan+srcmac, because the 802.1q payload is usuallyabsent due to hardware offload. This means a user can:1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmit_hash_policy (e.g. layer2+3).2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.This leaves bond->xdp_prog set but bond_xdp_check() now returning falsefor the same device. When the bond is later destroyed, dev_xdp_uninstall()calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hitsthe bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when anXDP program is loaded on a bond in 802.3ad or balance-xor mode.commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP")introduced bond_xdp_check() which returns false for 802.3ad/balance-xormodes when xmit_hash_policy is vlan+srcmac. The check was wired intobond_xdp_set() to reject XDP attachment with an incompatible policy, butthe symmetric path -- preventing xmit_hash_policy from being changed to anincompatible value after XDP is already loaded -- was left unguarded inbond_option_xmit_hash_policy_set().Note:commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode")later added a similar guard to bond_option_mode_set(), butbond_option_xmit_hash_policy_set() remained unprotected.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsqlite3-0 < 3.51.3-150000.3.39.1 (version in image is 3.51.2-150000.3.36.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: add bounds check for if_id in IRQ handlerThe IRQ handler extracts if_id from the upper 16 bits of the hardwarestatus register and uses it to index into ethsw->ports[] withoutvalidation. Since if_id can be any 16-bit value (0-65535) but the portsarray is only allocated with sw_attr.num_ifs elements, this can lead toan out-of-bounds read potentially.Add a bounds check before accessing the array, consistent with theexisting validation in dpaa2_switch_rx().
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zeroThe driver allocates arrays for ports, FDBs, and filter blocks usingkcalloc() with ethsw->sw_attr.num_ifs as the element count. When thedevice reports zero interfaces (either due to hardware configurationor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)instead of NULL.Later in dpaa2_switch_probe(), the NAPI initialization unconditionallyaccesses ethsw->ports[0]->netdev, which attempts to dereferenceZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.Add a check to ensure num_ifs is greater than zero after retrievingdevice attributes. This prevents the zero-sized allocations andsubsequent invalid pointer dereference.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entryEndpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-Xinterrupt to the host using a writel(), which generates a PCI posted writetransaction. There's no completion for posted writes, so the writel() mayreturn before the PCI write completes. dw_pcie_ep_raise_msix_irq() alsounmaps the outbound ATU entry used for the PCI write, so the write raceswith the unmap.If the PCI write loses the race with the ATU unmap, the write may corrupthost memory or cause IOMMU errors, e.g., these when running fio with alarger queue depth against nvmet-pci-epf: arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0Flush the write by performing a readl() of the same address to ensure thatthe write has reached the destination before the ATU entry is unmapped.The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but thereit was solved by dedicating an outbound iATU only for MSI. We can't do thesame for MSI-X because each vector can have a different msg_addr and themsg_addr may be changed while the vector is masked.[bhelgaas: commit log]
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.2.0280, a path traversal bypass in Vim's zip.vim plugin allows overwriting of arbitrary files when opening specially crafted zip archives, circumventing the previous fix for CVE-2025-53906. This vulnerability is fixed in 9.2.0280.
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.0110-150500.20.43.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.9.2).
-
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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: fix memory leak in update_eth_regs_async()When asynchronously writing to the device registers and if usb_submit_urb()fail, the code fail to release allocated to this point resources.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: A flaw was found in shadow-utils. When asking for a new password, shadow-utils asks the password twice. If the password fails on the second attempt, shadow-utils fails in cleaning the buffer used to store the first entry. This may allow an attacker with enough access to retrieve the password from the memory.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- login_defs < 4.17.2-150600.17.18.1 (version in image is 4.8.1-150600.17.9.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid chain re-validation if possibleHamza Mahfooz reports cpu soft lock-ups innft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547][..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables][..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables][..]Currently nf_tables will traverse the entire table (chain graph), startingfrom the entry points (base chains), exploring all possible paths(chain jumps). But there are cases where we could avoid revalidation.Consider:1 input -> j2 -> j32 input -> j2 -> j33 input -> j1 -> j2 -> j3Then the second rule does not need to revalidate j2, and, by extension j3,because this was already checked during validation of the first rule.We need to validate it only for rule 3.This is needed because chain loop detection also ensures we do not exceedthe jump stack: Just because we know that j2 is cycle free, its last jumpmight now exceed the allowed stack size. We also need to update allreachable chains with the new largest observed call depth.Care has to be taken to revalidate even if the chain depth won't be anissue: chain validation also ensures that expressions are not called frominvalid base chains. For example, the masquerade expression can only becalled from NAT postrouting base chains.Therefore we also need to keep record of the base chain context (type,hooknum) and revalidate if the chain becomes reachable from a differenthook location.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: dw: dmamux: fix OF node leak on route allocation failureMake sure to drop the reference taken to the DMA master OF node also onlate route allocation failures.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: bcm-sba-raid: fix device leak on probeMake sure to drop the reference taken when looking up the mailbox deviceduring probe on probe failures and on driver unbind.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: at_hdmac: fix device leak on of_dma_xlate()Make sure to drop the reference taken when looking up the DMA platformdevice during of_dma_xlate() when releasing channel resources.Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missingput_device() call in at_dma_xlate()") fixed the leak in a couple oferror paths but the reference is still leaking on successful allocation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gettext-runtime > 0-0 (version in image is 0.21.1-150600.3.3.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix memory leak in idpf_vport_rel()Free vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memoryduring a reset. Reported by kmemleak:unreferenced object 0xff450acac838a000 (size 4096): comm "kworker/u258:5", pid 7732, jiffies 4296830044 hex dump (first 32 bytes): 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ backtrace (crc 3da81902): __kmalloc_cache_noprof+0x469/0x7a0 idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf] idpf_init_task+0x1ec/0x8d0 [idpf] process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x251/0x2b0 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix kmemleak by releasing references to fault configfs itemsWhen CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blkdriver sets up fault injection support by creating the timeout_inject,requeue_inject, and init_hctx_fault_inject configfs items as childrenof the top-level nullbX configfs group.However, when the nullbX device is removed, the references taken tothese fault-config configfs items are not released. As a result,kmemleak reports a memory leak, for example:unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ecFix this by explicitly releasing the references to the fault-configconfigfs items when dropping the reference to the top-level nullbXconfigfs group.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: omap-dma: fix dma_pool resource leak in error pathsThe dma_pool created by dma_pool_create() is not destroyed whendma_async_device_register() or of_dma_controller_register() fails,causing a resource leak in the probe error paths.Add dma_pool_destroy() in both error paths to properly release theallocated dma_pool resource.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: etas_es58x: allow partial RX URB allocation to succeedWhen es58x_alloc_rx_urbs() fails to allocate the requested number ofURBs but succeeds in allocating some, it returns an error code.This causes es58x_open() to return early, skipping the cleanup label'free_urbs', which leads to the anchored URBs being leaked.As pointed out by maintainer Vincent Mailhol, the driver is designedto handle partial URB allocation gracefully. Therefore, partialallocation should not be treated as a fatal error.Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has beenallocated, restoring the intended behavior and preventing the leakin es58x_open().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,the function jumps to the out_scratch label without freeing the alreadyallocated dsaddrs list, leading to a memory leak.Fix this by jumping to the out_err_drain_dsaddrs label, which properlyfrees the dsaddrs list before cleaning up other resources.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In ems_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackems_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inems_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in ems_usb_close().Fix the memory leak by anchoring the URB in theems_usb_read_bulk_callback() to the dev->rx_submitted anchor.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Don't allow 0 for FOU_ATTR_IPPROTO.fou_udp_recv() has the same problem mentioned in the previouspatch.If FOU_ATTR_IPPROTO is set to 0, skb is not freed byfou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().Let's forbid 0 for FOU_ATTR_IPPROTO.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Initialize netdev pointer before queue setupIn setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq().However, the pointer to this structure is stored in oct->props[i].netdevonly after the calls to netif_set_real_num_rx_queues() andnetif_set_real_num_tx_queues().If either of these functions fails, setup_nic_devices() returns an errorwithout freeing the allocated netdev. Since oct->props[i].netdev is stillNULL at this point, the cleanup function liquidio_destroy_nic_device()will fail to find and free the netdev, resulting in a memory leak.Fix this by initializing oct->props[i].netdev before calling the queuesetup functions. This ensures that the netdev is properly accessible forcleanup in case of errors.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: atmel-sha204a - Fix OOM ->tfm_count leakIf memory allocation fails, decrement ->tfm_count to avoid blockingfuture reads.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: DISPUTED: The project has clarified that the documentation was incorrect, and that pkgutil.get_data() has the same security model as open(). The documentation has been updated to clarify this point. There is no vulnerability in the function if following the intended security model.pkgutil.get_data() did not validate the resource argument as documented, allowing path traversals.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.106.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.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).
- iproute2 < 6.4-150600.7.12.1 (version in image is 6.4-150600.7.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()Fix a memory leak in gpi_peripheral_config() where the original memorypointed to by gchan->config could be lost if krealloc() fails.The issue occurs when:1. gchan->config points to previously allocated memory2. krealloc() fails and returns NULL3. The function directly assigns NULL to gchan->config, losing the reference to the original memory4. The original memory becomes unreachable and cannot be freedFix this by using a temporary variable to hold the krealloc() resultand only updating gchan->config when the allocation succeeds.Found via static analysis and code review.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default < 6.4.0-150700.53.34.1 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: complete pending data exchange on device closeIn nci_close_device(), complete any pending data exchange beforeclosing. The data exchange callback (e.g.rawsock_data_exchange_complete) holds a socket reference.NIPA occasionally hits this leak:unreferenced object 0xff1100000f435000 (size 2048): comm "nci_dev", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: libexpat before 2.7.6 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.9.2).
-
Description: Issue summary: When a delta CRL that contains a Delta CRL Indicator extensionis processed a NULL pointer dereference might happen if the required CRLNumber extension is missing.Impact summary: A NULL pointer dereference can trigger a crash whichleads to a Denial of Service for an application.When CRL processing and delta CRL processing is enabled during X.509certificate verification, the delta CRL processing does not checkwhether the CRL Number extension is NULL before dereferencing it.When a malformed delta CRL file is being processed, this parametercan be NULL, causing a NULL pointer dereference.Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled inthe verification context, the certificate being verified to contain afreshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, andan attacker to provide a malformed CRL to an application that processes it.The vulnerability is limited to Denial of Service and cannot be escalated toachieve code execution or memory disclosure. For that reason the issue wasassessed as Low severity according to our Security Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the 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.16.1 (version in image is 1.1.1w-150700.11.11.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-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).