Description: etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, unauthorized users may bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients. In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to call MemberList and learn cluster topology, including member IDs and advertised endpoints; call Alarm, which can be abused for operational disruption or denial of service; use Lease APIs, interfering with TTL-based keys and lease ownership; and/or trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows. Kubernetes does not rely on etcd's built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected. Versions 3.4.42, 3.5.28, and 3.6.9 contain a patch. If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice. Restrict network access to etcd server ports so only trusted components can connect and/or require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
libpng16-16 > 0-0 (version in image is 1.6.43-slfo.1.1_3.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:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to version 0.28.1, when using a custom BuildKit frontend, the frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context. The issue has been fixed in v0.28.1. The vulnerability requires using an untrusted BuildKit frontend set with `#syntax` or `--build-arg BUILDKIT_SYNTAX`. Using these options with a well-known frontend image like `docker/dockerfile` is not affected.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
containerd > 0-0 (version in image is 1.7.29-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, an authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data store. Kubernetes does not rely on etcd's built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected. Versions 3.4.42, 3.5.28, and 3.6.9 contain a patch. If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice. Restrict network access to etcd server ports so only trusted components can connect and require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
libpng16-16 > 0-0 (version in image is 1.6.43-slfo.1.1_3.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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()nft_map_catchall_activate() has an inverted element activity checkcompared to its non-catchall counterpart nft_mapelem_activate() andcompared to what is logically required.nft_map_catchall_activate() is called from the abort path to re-activatecatchall map elements that were deactivated during a failed transaction.It should skip elements that are already active (they don't needre-activation) and process elements that are inactive (they need to berestored). Instead, the current code does the opposite: it skips inactiveelements and processes active ones.Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */The consequence is that when a DELSET operation is aborted,nft_setelem_data_activate() is never called for the catchall element.For NFT_GOTO verdict elements, this means nft_data_hold() is nevercalled to restore the chain->use reference count. Each abort cyclepermanently decrements chain->use. Once chain->use reaches zero,DELCHAIN succeeds and frees the chain while catchall verdict elementsstill reference it, resulting in a use-after-free.This is exploitable for local privilege escalation from an unprivilegeduser via user namespaces + nftables on distributions that enableCONFIG_USER_NS and CONFIG_NF_TABLES.Fix by removing the negation so the check matches nft_mapelem_activate():skip active elements, process inactive ones.
Packages affected:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix error recovery in macvlan_common_newlink()valis provided a nice repro to crash the kernel:ip link add p1 type veth peer p2ip link set address 00:00:00:00:00:20 dev p1ip link set up dev p1ip link set up dev p2ip link add mv0 link p2 type macvlan mode sourceip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20ping -c1 -I p1 1.2.3.4He also gave a very detailed analysis:The issue is triggered when a new macvlan link is created withMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (orMACVLAN_MACADDR_SET) parameter, lower device already has a macvlanport and register_netdevice() called from macvlan_common_newlink()fails (e.g. because of the invalid link name).In this case macvlan_hash_add_source is called frommacvlan_change_sources() / macvlan_common_newlink():This adds a reference to vlan to the port's vlan_source_hash usingmacvlan_source_entry.vlan is a pointer to the priv data of the link that is being created.When register_netdevice() fails, the error is returned frommacvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; }and free_netdev() is called, causing a kvfree() on the structnet_device that is still referenced in the source entry attached tothe lower device's macvlan port.Now all packets sent on the macvlan port with a matching source macaddress will trigger a use-after-free in macvlan_forward_source().With all that, my fix is to make sure we call macvlan_flush_sources()regardless of @create value whenever "goto destroy_macvlan_port;"path is taken.Many thanks to valis for following up on this issue.
Packages affected:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
libsystemd0 < 254.27-slfo.1.1_4.1 (version in image is 254.27-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: pyjwt is a JSON Web Token implementation in Python. An incorrect string comparison is run for `iss` checking, resulting in `"acb"` being accepted for `"_abc_"`. This is a bug introduced in version 2.10.0: checking the "iss" claim changed from `isinstance(issuer, list)` to `isinstance(issuer, Sequence)`. Since str is a Sequnce, but not a list, `in` is also used for string comparison. This results in `if "abc" not in "__abcd__":` being checked instead of `if "abc" != "__abc__":`. Signature checks are still present so real world impact is likely limited to denial of service scenarios. This issue has been patched in version 2.10.1. All users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
python311-PyJWT < 2.12.1-slfo.1.1_1.1 (version in image is 2.9.0-slfo.1.1_1.2).
Description: Issue summary: PBMAC1 parameters in PKCS#12 files are missing validationwhich can trigger a stack-based buffer overflow, invalid pointer or NULLpointer dereference during MAC verification.Impact summary: The stack buffer overflow or NULL pointer dereference maycause a crash leading to Denial of Service for an application that parsesuntrusted PKCS#12 files. The buffer overflow may also potentially enablecode execution depending on platform mitigations.When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2salt and keylength parameters from the file are used without validation.If the value of keylength exceeds the size of the fixed stack buffer usedfor the derived key (64 bytes), the key derivation will overflow the buffer.The overflow length is attacker-controlled. Also, if the salt parameter isnot an OCTET STRING type this can lead to invalid or NULL pointerdereference.Exploiting this issue requires a user or application to processa maliciously crafted PKCS#12 file. It is uncommon to accept untrustedPKCS#12 files in applications as they are usually used to store privatekeys which are trusted by definition. For this reason the issue was assessedas Moderate severity.The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, asPKCS#12 processing is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they donot support PBMAC1 in PKCS#12.
Packages affected:
libopenssl3 > 0-0 (version in image is 3.1.4-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.
Packages affected:
libpython3_11-1_0 < 3.11.15-slfo.1.1_1.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
containerd > 0-0 (version in image is 1.7.29-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.
Packages affected:
libpython3_11-1_0 < 3.11.15-slfo.1.1_1.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: libcurl can in some circumstances reuse the wrong connection when asked to doan Negotiate-authenticated HTTP or HTTPS request.libcurl features a pool of recent connections so that subsequent requests canreuse an existing connection to avoid overhead.When reusing a connection a range of criterion must first be met. Due to alogical error in the code, a request that was issued by an application couldwrongfully reuse an existing connection to the same server that wasauthenticated using different credentials. One underlying reason being thatNegotiate sometimes authenticates *connections* and not *requests*, contraryto how HTTP is designed to work.An application that allows Negotiate authentication to a server (that respondswanting Negotiate) with `user1:password1` and then does another operation tothe same server also using Negotiate but with `user2:password2` (while theprevious connection is still alive) - the second request wrongly reused thesame connection and since it then sees that the Negotiate negotiation isalready made, it just sends the request over that connection thinking it usesthe user2 credentials when it is in fact still using the connectionauthenticated for user1...The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.Applications can disable libcurl's reuse of connections and thus mitigate thisproblem, by using one of the following libcurl options to alter howconnections are or are not reused: `CURLOPT_FRESH_CONNECT`,`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using thecurl_multi API).
Packages affected:
curl < 8.14.1-slfo.1.1_6.1 (version in image is 8.14.1-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: time provides date and time handling in Rust. From 0.3.6 to before 0.3.47, when user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario. A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.
Packages affected:
aardvark-dns > 0-0 (version in image is 1.12.2-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
python311-PyJWT < 2.12.1-slfo.1.1_1.1 (version in image is 2.9.0-slfo.1.1_1.2).
Description: BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to version 0.28.1, insufficient validation of Git URL fragment subdir components may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem. The issue has been fixed in version v0.28.1 The issue affects only builds that use Git URLs with a subpath component. As a workaround, avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
glibc > 0-0 (version in image is 2.38-slfo.1.1_6.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
liblzma5 > 0-0 (version in image is 5.4.3-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Enforce that teql can only be used as root qdiscDesign intent of teql is that it is only supposed to be used as root qdisc.We need to check for that constraint.Although not important, I will describe the scenario that unearthed thisissue for the curious.GangMin Kim managed to concot a scenario as follows:ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s ── class 1:2 (weight=1, lmax=1514) teqlGangMin sends a packet which is enqueued to 1:1 (netem).Any invocation of dequeue by QFQ from this class will not return a packetuntil after 6.4s. In the meantime, a second packet is sent and it lands on1:2. teql's enqueue will return success and this will activate class 1:2.Main issue is that teql only updates the parent visible qlen (sch->q.qlen)at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql'speek always returns NULL), dequeue will never be called and thus the qlenwill remain as 0. With that in mind, when GangMin updates 1:2's lmax value,the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc'sqlen was not incremented, qfq fails to deactivate the class, but stillfrees its pointers from the aggregate. So when the first packet isrescheduled after 6.4 seconds (netem's delay), a dangling pointer isaccessed causing GangMin's causing a UAF.
Packages affected:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.
Packages affected:
libpython3_11-1_0 < 3.11.14-slfo.1.1_3.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
libpython3_11-1_0 < 3.11.14-slfo.1.1_3.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
Packages affected:
libpython3_11-1_0 < 3.11.15-slfo.1.1_1.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g.
Packages affected:
podman > 0-0 (version in image is 5.4.2-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: It was discovered that dpkg-deb (a component of dpkg, the Debian package management system) does not properly validate the end of the data stream when uncompressing a zstd-compressed .deb archive, which may result in denial of service (infinite loop spinning the CPU).
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
update-alternatives < 1.22.0-slfo.1.1_3.1 (version in image is 1.22.0-slfo.1.1_2.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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
openssh > 0-0 (version in image is 9.6p1-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
gpg2 > 0-0 (version in image is 2.4.4-slfo.1.1_7.1).
Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.
Packages affected:
libexslt0 < 1.1.38-slfo.1.1_6.1 (version in image is 1.1.38-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
python311-cryptography < 42.0.4-slfo.1.1_3.1 (version in image is 42.0.4-slfo.1.1_2.1).
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:
glibc > 0-0 (version in image is 2.38-slfo.1.1_6.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.
Packages affected:
libexslt0 < 1.1.38-slfo.1.1_6.1 (version in image is 1.1.38-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tilcdc: Fix removal actions in case of failed probeThe drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpersshould only be called when the device has been successfully registered.Currently, these functions are called unconditionally in tilcdc_fini(),which causes warnings during probe deferral scenarios.[ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68...[ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108[ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8[ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144[ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc][ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]Fix this by rewriting the failed probe cleanup path using the standardgoto error handling pattern, which ensures that cleanup functions areonly called on successfully initialized resources. Additionally, removethe now-unnecessary is_registered flag.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: stm32: dmamux: fix device leak on route allocationMake sure to drop the reference taken when looking up the DMA muxplatform device during route allocation.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A flaw was found in NetworkManager. The NetworkManager package allows access to files that may belong to other users. NetworkManager allows non-root users to configure the system's network. The daemon runs with root privileges and can access files owned by users different from the one who added the connection.
Packages affected:
NetworkManager > 0-0 (version in image is 1.42.6-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failureWhen a DAMOS-scheme DAMON sysfs directory setup fails after setup ofaccess_pattern/ directory, subdirectories of access_pattern/ directory arenot cleaned up. As a result, DAMON sysfs interface is nearly broken untilthe system reboots, and the memory for the unremoved directory is leaked.Cleanup the directories under such failures.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: cleanup attrs subdirs on context dir setup failureWhen a context DAMON sysfs directory setup is failed after setup of attrs/directory, subdirectories of attrs/ directory are not cleaned up. As aresult, DAMON sysfs interface is nearly broken until the system reboots,and the memory for the unremoved directory is leaked.Cleanup the directories under such failures.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writesDuring SPO tests, when mounting F2FS, an -EINVAL error was returned fromf2fs_recover_inode_page. The issue occurred under the following scenarioThread A Thread Bf2fs_ioc_commit_atomic_write - f2fs_do_sync_file // atomic = true - f2fs_fsync_node_pages : last_folio = inode folio : schedule before folio_lock(last_folio) f2fs_write_checkpoint - block_operations// writeback last_folio - schedule before f2fs_flush_nat_entries : set_fsync_mark(last_folio, 1) : set_dentry_mark(last_folio, 1) : folio_mark_dirty(last_folio) - __write_node_folio(last_folio) : f2fs_down_read(&sbi->node_write)//block - f2fs_flush_nat_entries : {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED) - unblock_operations : f2fs_up_write(&sbi->node_write) f2fs_write_checkpoint//return : f2fs_do_write_node_page()f2fs_ioc_commit_atomic_write//return SPOThread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio hasalready been written once. However, the {struct nat_entry}->flag did nothave the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) andwrite last_folio again after Thread B finishes f2fs_write_checkpoint.After SPO and reboot, it was detected that {struct node_info}->blk_addrwas not NULL_ADDR because Thread B successfully write the checkpoint.This issue only occurs in atomic write scenarios. For regular filefsync operations, the folio must be dirty. Ifblock_operations->f2fs_sync_node_pages successfully submit the foliowrite, this path will not be executed. Otherwise, thef2fs_write_checkpoint will need to wait for the folio write submissionto complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, thesituation where f2fs_need_dentry_mark checks that the {structnat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write hasalready been submitted, will not occur.Therefore, for atomic file fsync, sbi->node_write should be acquiredthrough __write_node_folio to ensure that the IS_CHECKPOINTED flagcorrectly indicates that the checkpoint write has been completed.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: align net_device lifecycle with bind/unbindCurrently, the net_device is allocated in ncm_alloc_inst() and freed inncm_free_inst(). This ties the network interface's lifetime to theconfiguration instance rather than the USB connection (bind/unbind).This decoupling causes issues when the USB gadget is disconnected wherethe underlying gadget device is removed. The net_device can outlive itsparent, leading to dangling sysfs links and NULL pointer dereferenceswhen accessing the freed gadget device.Problem 1: NULL pointer dereference on disconnect Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __pi_strlen+0x14/0x150 rtnl_fill_ifinfo+0x6b4/0x708 rtmsg_ifinfo_build_skb+0xd8/0x13c rtmsg_ifinfo+0x50/0xa0 __dev_notify_flags+0x4c/0x1f0 dev_change_flags+0x54/0x70 do_setlink+0x390/0xebc rtnl_newlink+0x7d0/0xac8 rtnetlink_rcv_msg+0x27c/0x410 netlink_rcv_skb+0x134/0x150 rtnetlink_rcv+0x18/0x28 netlink_unicast+0x254/0x3f0 netlink_sendmsg+0x2e0/0x3d4Problem 2: Dangling sysfs symlinks console:/ # ls -l /sys/class/net/ncm0 lrwxrwxrwx ... /sys/class/net/ncm0 -> /sys/devices/platform/.../gadget.0/net/ncm0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/ncm0 ls: .../gadget.0/net/ncm0: No such file or directoryMove the net_device allocation to ncm_bind() and deallocation toncm_unbind(). This ensures the network interface exists only when thegadget function is actually bound to a configuration.To support pre-bind configuration (e.g., setting interface name or MACaddress via configfs), cache user-provided options in f_ncm_optsusing the gether_opts structure. Apply these cached settings to thenet_device upon creation in ncm_bind().Preserve the use-after-free fix from commit 6334b8e4553c ("usb: gadget:f_ncm: Fix UAF ncm object at re-bind after usb ep transport error").Check opts->net in ncm_set_alt() and ncm_disable() to ensuregether_disconnect() runs only if a connection was established.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
python311-requests > 0-0 (version in image is 2.32.4-slfo.1.1_1.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:
libsystemd0 < 254.27-slfo.1.1_4.1 (version in image is 254.27-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
libsqlite3-0 < 3.51.3-slfo.1.1_1.1 (version in image is 3.50.4-slfo.1.1_1.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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.
Packages affected:
vim-data-common < 9.2.0110-slfo.1.1_1.1 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product. NOTE: pyminizip through 0.2.6 is also vulnerable because it bundles an affected zlib version, and exposes the applicable MiniZip code through its compress API.
Packages affected:
libz1 < 1.2.13-slfo.1.1_2.1 (version in image is 1.2.13-slfo.1.1_1.3).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).
Packages affected:
libgnutls30 < 3.8.3-slfo.1.1_6.1 (version in image is 3.8.3-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)
Packages affected:
openssh < 9.6p1-slfo.1.1_3.1 (version in image is 9.6p1-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Issue summary: A TLS 1.3 connection using certificate compression can beforced to allocate a large buffer before decompression without checkingagainst the configured certificate size limit.Impact summary: An attacker can cause per-connection memory allocations ofup to approximately 22 MiB and extra CPU work, potentially leading toservice degradation or resource exhaustion (Denial of Service).In affected configurations, the peer-supplied uncompressed certificatelength from a CompressedCertificate message is used to grow a heap bufferprior to decompression. This length is not bounded by the max_cert_listsetting, which otherwise constrains certificate message sizes. An attackercan exploit this to cause large per-connection allocations followed byhandshake failure. No memory corruption or information disclosure occurs.This issue only affects builds where TLS 1.3 certificate compression iscompiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compressionalgorithm (brotli, zlib, or zstd) is available, and where the compressionextension is negotiated. Both clients receiving a server CompressedCertificateand servers in mutual TLS scenarios receiving a client CompressedCertificateare affected. Servers that do not request client certificates are notvulnerable to client-initiated attacks.Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSIONto disable receiving compressed certificates.The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,as the TLS implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
Packages affected:
libopenssl3 > 0-0 (version in image is 3.1.4-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.
Packages affected:
libexslt0 < 1.1.38-slfo.1.1_6.1 (version in image is 1.1.38-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
libfreetype6 < 2.14.2-slfo.1.1_1.1 (version in image is 2.13.3-slfo.1.1_1.1).
Description: zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.
Packages affected:
libz1 < 1.2.13-slfo.1.1_2.1 (version in image is 1.2.13-slfo.1.1_1.3).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.
Packages affected:
vim-data-common < 9.2.0110-slfo.1.1_1.1 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
libssh-config < 0.10.6-slfo.1.1_5.1 (version in image is 0.10.6-slfo.1.1_4.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: An issue was discovered in hyper v0.13.7. h2-0.2.4 Stream stacking occurs when the H2 component processes HTTP2 RST_STREAM frames. As a result, the memory and CPU usage are high which can lead to a Denial of Service (DoS).
Packages affected:
netavark > 0-0 (version in image is 1.12.2-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a redirect to a second URL, curl could leak that token to the secondhostname under some circumstances.If the hostname that the first request is redirected to has information in theused .netrc file, with either of the `machine` or `default` keywords, curlwould pass on the bearer token set for the first host also to the second one.
Packages affected:
curl < 8.14.1-slfo.1.1_6.1 (version in image is 8.14.1-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
glibc > 0-0 (version in image is 2.38-slfo.1.1_6.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
glibc > 0-0 (version in image is 2.38-slfo.1.1_6.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to aserver, even if the new request uses different credentials for the HTTP proxy.The proper behavior is to create or use a separate connection.
Packages affected:
curl < 8.14.1-slfo.1.1_6.1 (version in image is 8.14.1-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A flaw was found in github.com/go-viper/mapstructure/v2, in the field processing component using mapstructure.WeakDecode. This vulnerability allows information disclosure through detailed error messages that may leak sensitive input values via malformed user-supplied data processed in security-critical contexts.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
containerd > 0-0 (version in image is 1.7.29-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - request reserved interrupt for virtual functionThe device interrupt vector 3 is an error interrupt forphysical function and a reserved interrupt for virtual function.However, the driver has not registered the reserved interrupt forvirtual function. When allocating interrupts, the number of interruptsis allocated based on powers of two, which includes this interrupt.When the system enables GICv4 and the virtual function passthroughto the virtual machine, releasing the interrupt in the drivertriggers a warning.The WARNING report is:WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4Therefore, register a reserved interrupt for VF and set theIRQF_NO_AUTOEN flag to avoid that warning.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_rbtree: validate open interval overlap[ Upstream commit 648946966a08e4cb1a71619e3d1b12bd7642de7b ]Open intervals do not have an end element, in particular an openinterval at the end of the set is hard to validate because of it islacking the end element, and interval validation relies on such endelement to perform the checks.This patch adds a new flag field to struct nft_set_elem, this is not anissue because this is a temporary object that is allocated in the stackfrom the insert/deactivate path. This flag field is used to specify thatthis is the last element in this add/delete command.The last flag is used, in combination with the start element cookie, tocheck if there is a partial overlap, eg. Already exists: 255.255.255.0-255.255.255.254 Add interval: 255.255.255.0-255.255.255.255 ~~~~~~~~~~~~~ start element overlapBasically, the idea is to check for an existing end element in the setif there is an overlap with an existing start element.However, the last open interval can come in any position in the addcommand, the corner case can get a bit more complicated: Already exists: 255.255.255.0-255.255.255.254 Add intervals: 255.255.255.0-255.255.255.255,255.255.255.0-255.255.255.254 ~~~~~~~~~~~~~ start element overlapTo catch this overlap, annotate that the new start element is a possibleoverlap, then report the overlap if the next element is another startelement that confirms that previous element in an open interval at theend of the set.For deletions, do not update the start cookie when deleting an openinterval, otherwise this can trigger spurious EEXIST when adding newelements.Unfortunately, there is no NFT_SET_ELEM_INTERVAL_OPEN flag which wouldmake easier to detect open interval overlaps.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When libcurl is asked to perform automatic gzip decompression ofcontent-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow wouldmake libcurl perform a buffer overflow.
Packages affected:
curl > 0-0 (version in image is 8.14.1-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
Packages affected:
libpython3_11-1_0 < 3.11.15-slfo.1.1_1.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
libsqlite3-0 < 3.51.3-slfo.1.1_1.1 (version in image is 3.50.4-slfo.1.1_1.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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.
Packages affected:
vim-data-common < 9.2.0110-slfo.1.1_1.1 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues
Packages affected:
libpython3_11-1_0 < 3.11.15-slfo.1.1_1.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.
Packages affected:
libexslt0 < 1.1.38-slfo.1.1_6.1 (version in image is 1.1.38-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to version 46.0.6, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named bar.example.com to validate against a wildcard leaf certificate for *.example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for bar.example.com. This issue has been patched in version 46.0.6.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
python311-cryptography > 0-0 (version in image is 42.0.4-slfo.1.1_2.1).
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actualuser on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.
Packages affected:
podman > 0-0 (version in image is 5.4.2-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
Packages affected:
libncurses6 > 0-0 (version in image is 6.4.20240224-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
iproute2 > 0-0 (version in image is 6.3-slfo.1.1_1.2).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues.This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64 alphabet they are expecting or verify that their application would not be affected if the b64decode() functions accepted "+" or "/" outside of altchars.
Packages affected:
libpython3_11-1_0 < 3.11.14-slfo.1.1_3.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
libexslt0 < 1.1.38-slfo.1.1_6.1 (version in image is 1.1.38-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.
Packages affected:
libexslt0 < 1.1.38-slfo.1.1_6.1 (version in image is 1.1.38-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default < 6.4.0-40.1 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: The "tarfile" module would still apply normalization of AREGTYPE (\x00) blocks to DIRTYPE, even while processing a multi-block member such as GNUTYPE_LONGNAME or GNUTYPE_LONGLINK. This could result in a crafted tar archive being misinterpreted by the tarfile module compared to other implementations.
Packages affected:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
libpython3_11-1_0 < 3.11.15-slfo.1.1_1.1 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
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:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-39.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).
Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.12).