-
Description: A flaw was found in Samba, in the front-end WINS hook handling: NetBIOS names from registration packets are passed to a shell without proper validation or escaping. Unsanitized NetBIOS name data from WINS registration packets are inserted into a shell command and executed by the Samba Active Directory Domain Controller's wins hook, allowing an unauthenticated network attacker to achieve remote command execution as the Samba process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- samba-client-libs < 4.15.13+git.664.e8416d8d213-3.99.1 (version in image is 4.15.13+git.625.ac658f2f12-3.88.1).
-
Description: REST client for Ruby (aka rest-client) before 1.8.0 allows remote attackers to conduct session fixation attacks or obtain sensitive cookie information by leveraging passage of cookies set in a response to a redirect.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-requests > 0-0 (version in image is 2.24.0-8.14.1).
-
Description: Salt before 2015.8.11 allows deleted minions to read or write to minions with the same id, related to caching.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- salt > 0-0 (version in image is 3000-74.1).
-
Description: NSS (Network Security Services) versions prior to 3.73 or 3.68.1 ESR are vulnerable to a heap overflow when handling DER-encoded DSA or RSA-PSS signatures. Applications using NSS for handling signatures encoded within CMS, S/MIME, PKCS \#7, or PKCS \#12 are likely to be impacted. Applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted, depending on how they configure NSS. *Note: This vulnerability does NOT impact Mozilla Firefox.* However, email clients and PDF viewers that use NSS for signature verification, such as Thunderbird, LibreOffice, Evolution and Evince are believed to be impacted. This vulnerability affects NSS < 3.73 and NSS < 3.68.1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: Heap buffer overflow in sqlite in Google Chrome prior to 112.0.5615.137 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsqlite3-0 < 3.44.0-9.29.1 (version in image is 3.39.3-9.26.1).
-
Description: A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- rsync < 3.1.3-3.22.1 (version in image is 3.1.3-3.14.1).
-
Description: BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability.The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: Memory safety bugs present in Firefox 141 and Thunderbird 141. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 142 and Thunderbird < 142.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- mozilla-nss-certs < 3.112.2-58.133.1 (version in image is 3.90-58.104.1).
-
Description: named in ISC BIND 9.x before 9.9.8-P4 and 9.10.x before 9.10.3-P4 allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a crafted signature record for a DNAME record, related to db.c and resolver.c.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- less < 458-7.15.1 (version in image is 458-7.9.1).
-
Description: Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils < 9.11.22-3.65.1 (version in image is 9.11.22-3.49.1).
-
Description: An issue was discovered in Linux: KVM through Improper handling of VM_IO|VM_PFNMAP vmas in KVM can bypass RO checks and can lead to pages being freed while still accessible by the VMM and guest. This allows users with the ability to start and control a VM to read/write random pages of memory and can result in local privilege escalation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: There's a possible overflow in handle_image() when shim tries to load and execute crafted EFI executables; The handle_image() function takes into account the SizeOfRawData field from each section to be loaded. An attacker can leverage this to perform out-of-bound writes into memory. Arbitrary code execution is not discarded in such scenario.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: The Salt-SSH pre-flight option copies the script to the target at a predictable path, which allows an attacker to force Salt-SSH to run their script. If an attacker has access to the target VM and knows the path to the pre-flight script before it runs they can ensure Salt-SSH runs their script with the privileges of the user running Salt-SSH. Do not make the copy path on the target predictable and ensure we check return codes of the scp command if the copy fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- salt > 0-0 (version in image is 3000-74.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldiscAny unprivileged user can attach N_GSM0710 ldisc, but it requiresCAP_NET_ADMIN to create a GSM network anyway.Require initial namespace CAP_NET_ADMIN to do that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.
Packages affected:
- libpython3_4m1_0 < 3.4.10-25.124.1 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: wall in util-linux through 2.40, often installed with setgid tty permissions, allows escape sequences to be sent to other users' terminals through argv. (Specifically, escape sequences received from stdin are blocked, but escape sequences received from argv are not blocked.) There may be plausible scenarios where this leads to account takeover.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libblkid1 < 2.33.2-4.36.1 (version in image is 2.33.2-4.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right usernsWhat we want is to verify there is that clone won't expose somethinghidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo"may be a result of MNT_LOCKED on a child, but it may also come fromlacking admin rights in the userns of the namespace mount belongs to.clone_private_mnt() checks the former, but not the latter.There's a number of rather confusing CAP_SYS_ADMIN checks in varioususerns during the mount, especially with the new mount API; they servedifferent purposes and in case of clone_private_mnt() they usually,but not always end up covering the missing check mentioned above.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.116.1).
-
Description: A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allow_active" user. The highest risk is that the attacker can then perform all allow_active yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- pam < 1.1.8-24.71.1 (version in image is 1.1.8-24.49.1).
-
Description: The Fiddle::Handle implementation in ext/fiddle/handle.c in Ruby before 2.0.0-p648, 2.1 before 2.1.8, and 2.2 before 2.2.4, as distributed in Apple OS X before 10.11.4 and other products, mishandles tainting, which allows context-dependent attackers to execute arbitrary code or cause a denial of service (application crash) via a crafted string, related to the DL module and the libffi library. NOTE: this vulnerability exists because of a CVE-2009-5147 regression.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- ruby > 0-0 (version in image is 2.1-1.6).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hisilicon: Fix potential use-after-free in hisi_femac_rx()The skb is delivered to napi_gro_receive() which may free it, aftercalling this, dereferencing skb may trigger use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A heap-based buffer overflow was found in the Linux kernel's LightNVM subsystem. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length heap-based buffer. This vulnerability allows a local attacker to escalate privileges and execute arbitrary code in the context of the kernel. The attacker must first obtain the ability to execute high-privileged code on the target system to exploit this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc < 2.22-114.34.1 (version in image is 2.22-114.31.1).
-
Description: An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.116.1).
-
Description: Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.116.1).
-
Description: When using a TarFile.errorlevel = 0 and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0 in affected versions is that the member would still be extracted and not skipped.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.116.1).
-
Description: A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.87.1 (version in image is 2.9.4-46.65.1).
-
Description: A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.87.1 (version in image is 2.9.4-46.65.1).
-
Description: Python Cryptographic Authority pyopenssl version prior to version 17.5.0 contains a CWE-416: Use After Free vulnerability in X509 object handling that can result in Use after free can lead to possible denial of service or remote code execution.. This attack appear to be exploitable via Depends on the calling application and if it retains a reference to the memory.. This vulnerability appears to have been fixed in 17.5.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-pyOpenSSL < 17.1.0-4.26.1 (version in image is 17.1.0-4.23.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix UAF in svc_tcp_listen_data_ready()After the listener svc_sock is freed, and before invoking svc_tcp_accept()for the established child sock, there is a window that the newsockretaining a freed listener svc_sock in sk_user_data which cloning fromparent. In the race window, if data is received on the newsock, we willobserve use-after-free report in svc_tcp_listen_data_ready().Reproduce by two tasks:1. while :; do rpc.nfsd 0 ; rpc.nfsd; done2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; doneKASAN report: ================================================================== BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] Read of size 8 at addr ffff888139d96228 by task nc/102553 CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: dump_stack_lvl+0x33/0x50 print_address_description.constprop.0+0x27/0x310 print_report+0x3e/0x70 kasan_report+0xae/0xe0 svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] tcp_data_queue+0x9f4/0x20e0 tcp_rcv_established+0x666/0x1f60 tcp_v4_do_rcv+0x51c/0x850 tcp_v4_rcv+0x23fc/0x2e80 ip_protocol_deliver_rcu+0x62/0x300 ip_local_deliver_finish+0x267/0x350 ip_local_deliver+0x18b/0x2d0 ip_rcv+0x2fb/0x370 __netif_receive_skb_one_core+0x166/0x1b0 process_backlog+0x24c/0x5e0 __napi_poll+0xa2/0x500 net_rx_action+0x854/0xc90 __do_softirq+0x1bb/0x5de do_softirq+0xcb/0x100 ... Allocated by task 102371: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7b/0x90 svc_setup_socket+0x52/0x4f0 [sunrpc] svc_addsock+0x20d/0x400 [sunrpc] __write_ports_addfd+0x209/0x390 [nfsd] write_ports+0x239/0x2c0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 102551: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x190 __kmem_cache_free+0x133/0x270 svc_xprt_free+0x1e2/0x350 [sunrpc] svc_xprt_destroy_all+0x25a/0x440 [sunrpc] nfsd_put+0x125/0x240 [nfsd] nfsd_svc+0x2cb/0x3c0 [nfsd] write_threads+0x1ac/0x2a0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcFix the UAF by simply doing nothing in svc_tcp_listen_data_ready()if state != TCP_LISTEN, that will avoid dereferencing svsk for allchild socket.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent < 20250327.01-1.50.1 (version in image is 20230601.00-1.32.3).
-
Description: Issue summary: Calling the OpenSSL API function SSL_free_buffers may causememory to be accessed that was previously freed in some situationsImpact summary: A use after free can have a range of potential consequences suchas the corruption of valid data, crashes or execution of arbitrary code.However, only applications that directly call the SSL_free_buffers function areaffected by this issue. Applications that do not call this function are notvulnerable. Our investigations indicate that this function is rarely used byapplications.The SSL_free_buffers function is used to free the internal OpenSSL buffer usedwhen processing an incoming record from the network. The call is only expectedto succeed if the buffer is not currently in use. However, two scenarios havebeen identified where the buffer is freed even when still in use.The first scenario occurs where a record header has been received from thenetwork and processed by OpenSSL, but the full record body has not yet arrived.In this case calling SSL_free_buffers will succeed even though a record has onlybeen partially processed and the buffer is still in use.The second scenario occurs where a full record containing application data hasbeen received and processed by OpenSSL but the application has only read part ofthis data. Again a call to SSL_free_buffers will succeed even though the bufferis still in use.While these scenarios could occur accidentally during normal operation amalicious attacker could attempt to engineer a stituation where this occurs.We are not aware of this issue being actively exploited.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
Packages affected:
- libopenssl1_1 < 1.1.1d-2.107.1 (version in image is 1.1.1d-2.98.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libfreetype6 < 2.6.3-7.21.1 (version in image is 2.6.3-7.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: reject malicious packets in ipv6_gso_segment()syzbot was able to craft a packet with very long IPv6 extension headersleading to an overflow of skb->transport_header.This 16bit field has a limited range.Add skb_reset_transport_header_careful() helper and use itfrom ipv6_gso_segment()WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151Modules linked in:CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151Call Trace: skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In libzypp before 20170803 it was possible to add unsigned YUM repositories without warning to the user that could lead to man in the middle or malicious servers to inject malicious RPM packages into a users system.
Packages affected:
- zypper > 0-0 (version in image is 1.13.64-21.55.2).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- gpg2 > 0-0 (version in image is 2.0.24-9.14.1).
-
Description: The display_debug_frames function in dwarf.c in GNU Binutils 2.29.1 allows remote attackers to cause a denial of service (integer overflow and heap-based buffer over-read, and application crash) or possibly have unspecified other impact via a crafted ELF file, related to print_debug_frame.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The print_gnu_property_note function in readelf.c in GNU Binutils 2.29.1 does not have integer-overflow protection on 32-bit platforms, which allows remote attackers to cause a denial of service (segmentation violation and application crash) or possibly have unspecified other impact via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: json-c through 0.14 has an integer overflow and out-of-bounds write via a large JSON file, as demonstrated by printbuf_memappend.
Packages affected:
- libfastjson4 < 0.99.8-3.6.1 (version in image is 0.99.8-3.3.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sudo < 1.8.27-4.51.1 (version in image is 1.8.27-4.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/nfc: fix use-after-free llcp_sock_bind/connectCommits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()")and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()")fixed a refcount leak bug in bind/connect but introduced ause-after-free if the same local is assigned to 2 different sockets.This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2);Fix this by assigning NULL to llcp_sock->local after callingnfc_llcp_local_put.This addresses CVE-2021-23134.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: Fix use-after-free after the TLS device goes down and upWhen a netdev with active TLS offload goes down, tls_device_down iscalled to stop the offload and tear down the TLS context. However, thesocket stays alive, and it still points to the TLS context, which is nowdeallocated. If a netdev goes up, while the connection is still active,and the data flow resumes after a number of TCP retransmissions, it willlead to a use-after-free of the TLS context.This commit addresses this bug by keeping the context alive until itsnormal destruction, and implements the necessary fallbacks, so that theconnection can resume in software (non-offloaded) kTLS mode.On the TX side tls_sw_fallback is used to encrypt all packets. The RXside already has all the necessary fallbacks, because receivingnon-decrypted packets is supported. The thing needed on the RX side isto block resync requests, which are normally produced after receivingnon-decrypted packets.The necessary synchronization is implemented for a graceful teardown:first the fallbacks are deployed, then the driver resources are released(it used to be possible to have a tls_dev_resync after tls_dev_del).A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallbackmode. It's used to skip the RX resync logic completely, as it becomesuseless, and some objects may be released (for example, resync_async,which is allocated and freed by the driver).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/mlx5: Fix initializing CQ fragments bufferThe function init_cq_frag_buf() can be called to initialize the current CQfragments buffer cq->buf, or the temporary cq->resize_buf that is filledduring CQ resize operation.However, the offending commit started to use function get_cqe() forgetting the CQEs, the issue with this change is that get_cqe() alwaysreturns CQEs from cq->buf, which leads us to initialize the wrong buffer,and in case of enlarging the CQ we try to access elements beyond the sizeof the current cq->buf and eventually hit a kernel panic. [exception RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core] [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread at ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95dddFix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() thattakes the correct source buffer as a parameter.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wl1251: Fix possible buffer overflow in wl1251_cmd_scanFunction wl1251_cmd_scan calls memcpy without checking the length.Harden by checking the length is within the maximum allowed size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix use after free on rmmodplat_dev->dev->platform_data is released by platform_device_unregister(),use of pclk and hclk is a use-after-free. Since device unregister won'tneed a clk device we adjust the function call sequence to fix this issue.[ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci][ 31.275563] Freed by task 306:[ 30.276782] platform_device_release+0x25/0x80
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blktrace: Fix uaf in blk_trace access after removing by sysfsThere is an use-after-free problem triggered by following process: P1(sda) P2(sdb) echo 0 > /sys/block/sdb/trace/enable blk_trace_remove_queue synchronize_rcu blk_trace_free relay_closercu_read_lock__blk_add_trace trace_note_tsk (Iterate running_trace_list) relay_close_buf relay_destroy_buf kfree(buf) trace_note(sdb's bt) relay_reserve buf->offset <- nullptr deference (use-after-free) !!!rcu_read_unlock[ 502.714379] BUG: kernel NULL pointer dereference, address:0000000000000010[ 502.715260] #PF: supervisor read access in kernel mode[ 502.715903] #PF: error_code(0x0000) - not-present page[ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0[ 502.717252] Oops: 0000 [#1] SMP[ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360[ 502.732872] Call Trace:[ 502.733193] __blk_add_trace.cold+0x137/0x1a3[ 502.733734] blk_add_trace_rq+0x7b/0xd0[ 502.734207] blk_add_trace_rq_issue+0x54/0xa0[ 502.734755] blk_mq_start_request+0xde/0x1b0[ 502.735287] scsi_queue_rq+0x528/0x1140...[ 502.742704] sg_new_write.isra.0+0x16e/0x3e0[ 502.747501] sg_ioctl+0x466/0x1100Reproduce method: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb, BLKTRACESTART) echo 0 > /sys/block/sdb/trace/enable & // Add delay(mdelay/msleep) before kernel enters blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Enters trace_note_tsk() after blk_trace_free() returned // Use mdelay in rcu region rather than msleep(which may schedule out)Remove blk_trace from running_list before calling blk_trace_free() bysysfs if blk_trace is at Blktrace_running state.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: destroy cm id before destroy qp to avoid use after freeWe should always destroy cm_id before destroy qp to avoid to get cmaevent after qp was destroyed, which may lead to use after free.In RDMA connection establishment error flow, don't destroy qp in cmevent handler.Just report cm_error to upper level, qp will be destroyin nvme_rdma_alloc_queue() after destroy cm id.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: Fix out-of-bound vmalloc access in imageblitThis issue happens when a userspace program does an ioctlFBIOPUT_VSCREENINFO passing the fb_var_screeninfo structcontaining only the fields xres, yres, and bits_per_pixelwith values.If this struct is the same as the previous ioctl, thevc_resize() detects it and doesn't call the resize_screen(),leaving the fb_var_screeninfo incomplete. And this leads tothe updatescrollmode() calculates a wrong value tofbcon_display->vrows, which makes the real_y() return awrong value of y, and that value, eventually, causesthe imageblit to access an out-of-bound address value.To solve this issue I made the resize_screen() be calledeven if the screen does not need any resizing, so it will"fix and fill" the fb_var_screeninfo independently.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requestsThe FSM can run in a circle allowing rdma_resolve_ip() to be called twiceon the same id_priv. While this cannot happen without going through thework, it violates the invariant that the same address resolutionbackground request cannot be active twice. CPU 1 CPU 2rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): for #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. handler still running ..]rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) !! two requests are now on the req_listrdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // process_one_req() self removes it spin_lock_bh(&lock); cancel_delayed_work(&req->work); if (!list_empty(&req->list)) == true ! rdma_addr_cancel() returns after process_on_req #1 is done kfree(id_priv) process_one_req(): for #2 addr_handler(): mutex_lock(&id_priv->handler_mutex); !! Use after free on id_privrdma_addr_cancel() expects there to be one req on the list and onlycancels the first one. The self-removal behavior of the work only happensafter the handler has returned. This yields a situations where thereq_list can have two reqs for the same "handle" but rdma_addr_cancel()only cancels the first one.The second req remains active beyond rdma_destroy_id() and willuse-after-free id_priv once it inevitably triggers.Fix this by remembering if the id_priv has called rdma_resolve_ip() andalways cancel before calling it again. This ensures the req_list nevergets more than one item in it and doesn't cost anything in the normal flowthat never uses this strange error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: Fix flipped sign in tls_err_abort() callssk->sk_err appears to expect a positive value, a convention that ktlsdoesn't always follow and that leads to memory corruption in other code.For instance, [kworker] tls_encrypt_done(..., err=) tls_err_abort(.., err) sk->sk_err = err; [task] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret is positive splice_from_pipe_feed (continued) ret = actor(...) // ret is still positive and interpreted as bytes // written, resulting in underflow of buf->len and // sd->len, leading to huge buf->offset and bogus // addresses computed in later calls to actor()Fix all tls_err_abort() callers to pass a negative error codeconsistently and centralize the error-prone sign flip there, throwing ina warning to catch future misuse and uninlining the function so itreally does only warn once.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: mma8452: Fix trigger reference coutingThe mma8452 driver directly assigns a trigger to the struct iio_dev. TheIIO core when done using this trigger will call `iio_trigger_put()` to dropthe reference count by 1.Without the matching `iio_trigger_get()` in the driver the reference countcan reach 0 too early, the trigger gets freed while still in use and ause-after-free occurs.Fix this by getting a reference to the trigger before assigning it to theIIO device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: oss: Fix negative period/buffer sizesThe period size calculation in OSS layer may receive a negative valueas an error, but the code there assumes only the positive values andhandle them with size_t. Due to that, a too big value may be passedto the lower layers.This patch changes the code to handle with ssize_t and adds the propererror checks appropriately.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: pch_can: pch_can_rx_normal: fix use after freeAfter calling netif_receive_skb(skb), dereferencing skb is unsafe.Especially, the can_frame cf which aliases skb memory is dereferencedjust after the call netif_receive_skb(skb).Reordering the lines solves the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()The free_rtllib() function frees the "dev" pointer so there is useafter free on the next line. Re-arrange things to avoid that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free flaw was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- less < 458-7.12.1 (version in image is 458-7.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Fix out-of-bound bugs caused by unset skb->mac_headerIf an AF_PACKET socket is used to send packets through ipvlan and thedefault xmit function of the AF_PACKET socket is changed fromdev_queue_xmit() to packet_direct_xmit() via setsockopt() with the optionname of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset andremains as the initial value of 65535, this may trigger slab-out-of-boundsbugs as following:=================================================================UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33all Trace:print_address_description.constprop.0+0x1d/0x160print_report.cold+0x4f/0x112kasan_report+0xa3/0x130ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]ipvlan_start_xmit+0x29/0xa0 [ipvlan]__dev_direct_xmit+0x2e2/0x380packet_direct_xmit+0x22/0x60packet_snd+0x7c9/0xc40sock_sendmsg+0x9a/0xa0__sys_sendto+0x18a/0x230__x64_sys_sendto+0x74/0x90do_syscall_64+0x3b/0x90entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit()In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() iscalled. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() whichuse "skb->head + skb->mac_header", out-of-bound access occurs.This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()and reset mac header in multicast to solve this out-of-bound bug.
Packages affected:
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix UAF when detecting digest errorsWe should also bail from the io_work loop when we set rd_enabled to true,so we don't attempt to read data from the socket when the TCP stream isalready out-of-sync or corrupted.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: vivid: fix compose size exceed boundarysyzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10[...] Call Trace: ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 This is because we forget to check boundary after adjust compose->heightint V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problemfor this case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid use-after-free in ip6_fragment()Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.It seems to not be always true, at least for UDP stack.syzbot reported:BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [inline] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fde3588c0d9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000aRBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 Allocated by task 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline] rt6_make_pcpu_route net/ipv6/route.c:1417 [inline] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [inline] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec n---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/khugepaged: invoke MMU notifiers in shmem/file collapse pathsAny codepath that zaps page table entries must invoke MMU notifiers toensure that secondary MMUs (like KVM) don't keep accessing pages whicharen't mapped anymore. Secondary MMUs don't hold their own references topages that are mirrored over, so failing to notify them can lead to pageuse-after-free.I'm marking this as addressing an issue introduced in commit f3f0e1d2150b("khugepaged: add support of collapse for tmpfs/shmem pages"), but most ofthe security impact of this only came in commit 27e1f8273113 ("khugepaged:enable collapse pmd for pte-mapped THP"), which actually omitted flushesfor the removal of present PTEs, not just for the removal of empty pagetables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: Fix use-after-free in tun_detach()syzbot reported use-after-free in tun_detach() [1]. This causes calltrace like below:==================================================================BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe cause of the issue is that sock_put() from __tun_detach() dropslast reference count for struct net, and then notifier_call_chain()from netdev_state_change() accesses that struct net.This patch fixes the issue by calling sock_put() from tun_detach()after all necessary accesses for the struct net has done.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: Fix potential use-after-freeThe skb is delivered to netif_rx() which may free it, after calling this,dereferencing skb may trigger use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZEI expect that the hardware will have limited this to 16, but just incase it hasn't, check for this corner case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix mpol_new leak in shared_policy_replaceIf mpol_new is allocated but not used in restart loop, mpol_new will befreed via mpol_put before returning to the caller. But refcnt is notinitialized yet, so mpol_put could not do the right things and mightleak the unused mpol_new. This would happen if mempolicy was updated onthe shared shmem file while the sp->lock has been dropped during thememory allocation.This issue could be triggered easily with the below code snippet ifthere are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: m_can: m_can_tx_handler(): fix use after free of skbcan_put_echo_skb() will clone skb then free the skb. Move thecan_put_echo_skb() for the m_can version 3.0.x directly before thestart of the xmit in hardware, similar to the 3.1.x branch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bfq: Update cgroup information before merging bioWhen the process is migrated to a different cgroup (or in case ofwriteback just starts submitting bios associated with a differentcgroup) bfq_merge_bio() can operate with stale cgroup information inbic. Thus the bio can be merged to a request from a different cgroup orit can result in merging of bfqqs for different cgroups or bfqqs ofalready dead cgroups and causing possible use-after-free issues. Fix theproblem by updating cgroup information in bfq_merge_bio().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - add param check for RSAReject requests with a source buffer that is bigger than the size of thekey. This is to prevent a possible integer underflow that might happenwhen copying the source scatterlist into a linear buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - add param check for DHReject requests with a source buffer that is bigger than the size of thekey. This is to prevent a possible integer underflow that might happenwhen copying the source scatterlist into a linear buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: Add boundary check in put_entry()Just like next_entry(), boundary check is necessary to prevent memoryout-of-bound access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name}Both dev_name and short_name are not guaranteed to be NULL terminated sothis instead use strnlen and then attempt to determine if the resultingstring needs to be truncated or not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()There is an use-after-free reported by KASAN: BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82 Read of size 1 at addr ffff888112afc460 by task modprobe/2111 CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), Call Trace: kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5 acpi_ds_store_object_to_local+0x15d/0x3a0 acpi_ex_store+0x78d/0x7fd acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b acpi_ps_parse_aml+0x217/0x8d5 ... The root cause of the problem is that the acpi_operand_objectis freed when acpi_ut_walk_package_tree() fails inacpi_ut_copy_ipackage_to_ipackage(), lead to repeated release inacpi_ut_copy_iobject_to_iobject(). The problem was introducedby "8aa5e56eeb61" commit, this commit is to fix memory leak inacpi_ut_copy_iobject_to_iobject(), repeatedly adding removeoperation, lead to "acpi_operand_object" used after free.Fix it by removing acpi_ut_remove_reference() inacpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()is called to copy an internal package object into another internalpackage object, when it fails, the memory of acpi_operand_objectshould be freed by the caller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Delay the unmapping of the bufferOn WCN3990, we are seeing a rare scenario where copy engine hardware issending a copy complete interrupt to the host driver while stillprocessing the buffer that the driver has sent, this is leading into anSMMU fault triggering kernel panic. This is happening on copy enginechannel 3 (CE3) where the driver normally enqueues WMI commands to thefirmware. Upon receiving a copy complete interrupt, host driver willimmediately unmap and frees the buffer presuming that hardware hasprocessed the buffer. In the issue case, upon receiving copy completeinterrupt, host driver will unmap and free the buffer but since hardwareis still accessing the buffer (which in this case got unmapped inparallel), SMMU hardware will trigger an SMMU fault resulting in akernel panic.In order to avoid this, as a work around, add a delay before unmappingthe copy engine source DMA buffer. This is conditionally done forWCN3990 and only for the CE3 channel where issue is seen.Below is the crash signature:wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandledcontext fault: fsr=0x402, iova=0x7fdfd8ac0,fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandledcontext fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal errorreceived: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149remoteproc remoteproc0: crash detected in4080000.remoteproc: type fatal error <3> remoteproc remoteproc0:handling crash #1 in 4080000.remoteprocpc : __arm_lpae_unmap+0x500/0x514lr : __arm_lpae_unmap+0x4bc/0x514sp : ffffffc011ffb530x29: ffffffc011ffb590 x28: 0000000000000000x27: 0000000000000000 x26: 0000000000000004x25: 0000000000000003 x24: ffffffc011ffb890x23: ffffffa762ef9be0 x22: ffffffa77244ef00x21: 0000000000000009 x20: 00000007fff7c000x19: 0000000000000003 x18: 0000000000000000x17: 0000000000000004 x16: ffffffd7a357d9f0x15: 0000000000000000 x14: 00fd5d4fa7ffffffx13: 000000000000000e x12: 0000000000000000x11: 00000000ffffffff x10: 00000000fffffe00x9 : 000000000000017c x8 : 000000000000000cx7 : 0000000000000000 x6 : ffffffa762ef9000x5 : 0000000000000003 x4 : 0000000000000004x3 : 0000000000001000 x2 : 00000007fff7c000x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:__arm_lpae_unmap+0x500/0x514__arm_lpae_unmap+0x4bc/0x514__arm_lpae_unmap+0x4bc/0x514arm_lpae_unmap_pages+0x78/0xa4arm_smmu_unmap_pages+0x78/0x104__iommu_unmap+0xc8/0x1e4iommu_unmap_fast+0x38/0x48__iommu_dma_unmap+0x84/0x104iommu_dma_free+0x34/0x50dma_free_attrs+0xa4/0xd0ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c[ath10k_core]ath10k_halt+0x11c/0x180 [ath10k_core]ath10k_stop+0x54/0x94 [ath10k_core]drv_stop+0x48/0x1c8 [mac80211]ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c[mac80211]__dev_open+0xb4/0x174__dev_change_flags+0xc4/0x1dcdev_change_flags+0x3c/0x7cdevinet_ioctl+0x2b4/0x580inet_ioctl+0xb0/0x1b4sock_do_ioctl+0x4c/0x16ccompat_ifreq_ioctl+0x1cc/0x35ccompat_sock_ioctl+0x110/0x2ac__arm64_compat_sys_ioctl+0xf4/0x3e0el0_svc_common+0xb4/0x17cel0_svc_compat_handler+0x2c/0x58el0_svc_compat+0x8/0x2cTested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege.There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock.When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable.The setsockopt TCP_ULP operation does not require any privilege.We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root.We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: Use After Free in GitHub repository vim/vim prior to 9.0.1857.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.
Packages affected:
- kernel-default < 4.12.14-122.189.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free bug in cifs_debug_data_proc_show()Skip SMB sessions that are being teared down(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()to avoid use-after-free in @ses.This fixes the following GPF when reading from /proc/fs/cifs/DebugDatawhile mounting and umounting [ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: don't skip expired elements during walkThere is an asymmetry between commit/abort and preparation phase if thefollowing conditions are met:1. set is a verdict map ("1.2.3.4 : jump foo")2. timeouts are enabledIn this case, following sequence is problematic:1. element E in set S refers to chain C2. userspace requests removal of set S3. kernel does a set walk to decrement chain->use count for all elements from preparation phase4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase)If E has already expired in 1), it will be ignored during list walk, so its use countwon't have been changed.Then, when set is culled, ->destroy callback will zap the element vianf_tables_set_elem_destroy(), but this function is only safe forelements that have been deactivated earlier from the preparation phase:lack of earlier deactivate removes the element but leaks the chain usecount, which results in a WARN splat when the chain gets removed later,plus a leak of the nft_chain structure.Update pipapo_get() not to skip expired elements, otherwise flushcommand reports bogus ENOENT errors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: allow exp not to be removed in nf_ct_find_expectationCurrently nf_conntrack_in() calling nf_ct_find_expectation() willremove the exp from the hash table. However, in some scenario, weexpect the exp not to be removed when the created ct will not beconfirmed, like in OVS and TC conntrack in the following patches.This patch allows exp not to be removed by setting IPS_CONFIRMEDin the status of the tmpl.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()The function lio_target_nacl_info_show() uses sprintf() in a loop to printdetails for every iSCSI connection in a session without checking for thebuffer length. With enough iSCSI connections it's possible to overflow thebuffer provided by configfs and corrupt the memory.This patch replaces sprintf() with sysfs_emit_at() that checks for bufferboundries.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: raid1: fix potential OOB in raid1_remove_disk()If rddev->raid_disk is greater than mddev->raid_disks, there will bean out-of-bounds in raid1_remove_disk(). We have already foundsimilar reports as follows:1) commit d17f744e883b ("md-raid10: fix KASAN warning")2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")Fix this bug by checking whether the "number" variable isvalid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: Use After Free in GitHub repository vim/vim prior to v9.0.2010.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.0.2103-17.26.1 (version in image is 9.0.1894-17.23.2).
-
Description: A heap out-of-bounds write vulnerability in the Linux kernel's Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation.If perf_read_group() is called while an event's sibling_list is smaller than its child's sibling_list, it can increment or write to memory locations outside of the allocated buffer.We recommend upgrading past commit 32671e3799ca2e4590773fd0e63aaa4229e50c06.
Packages affected:
- kernel-default < 4.12.14-122.183.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT.We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
Packages affected:
- kernel-default < 4.12.14-122.189.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Vim before 9.0.2142 has a stack-based buffer overflow because did_set_langmap in map.c calls sprintf to write to the error buffer that is passed down to the option callback functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.
Packages affected:
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: handle backlogging of crypto requestsSince we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on ourrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, whenthe cryptd queue for AESNI is full (easy to trigger with anartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueuedto the backlog but still processed. In that case, the async callbackwill also be called twice: first with err == -EINPROGRESS, which itseems we can just ignore, then with err == 0.Compared to Sabrina's original patch this version uses the newtls_*crypt_async_wait() helpers and converts the EBUSY toEINPROGRESS to avoid having to modify all the error handlingpaths. The handling is identical.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tomoyo: fix UAF write bug in tomoyo_write_control()Since tomoyo_write_control() updates head->write_buf when write()of long lines is requested, we need to fetch head->write_buf afterhead->io_sem is held. Otherwise, concurrent write() requests cancause use-after-free-write and double-free problems.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ipv6: avoid possible UAF in ip6_route_mpath_notify()syzbot found another use-after-free in ip6_route_mpath_notify() [1]Commit f7225172f25a ("net/ipv6: prevent use after free inip6_route_mpath_notify") was not able to fix the root cause.We need to defer the fib6_info_release() calls afterip6_route_mpath_notify(), in the cleanup phase.[1]BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77RIP: 0033:0x7f73dd87dda9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 m---truncated---
Packages affected:
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix double free of the ha->vp_map pointerCoverity scan reported potential risk of double free of the pointerha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freedin function qla2x00_mem_free(ha).Assign NULL to vp_map and kfree take care of NULL.
Packages affected:
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: edia: dvbdev: fix a use-after-freeIn dvb_register_device, *pdvbdev is set equal to dvbdev, which is freedin several error-handling paths. However, *pdvbdev is not set to NULLafter dvbdev's deallocation, causing use-after-frees in many places,for example, in the following call chain:budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_putWhen calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev indvb_register_device) could point to memory that had been freed indvb_register_device. Thereafter, this pointer is transferred tokref_put and triggering a use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix use-after-free bugs caused by sco_sock_timeoutWhen the sco connection is established and then, the sco socketis releasing, timeout_work will be scheduled to judge whetherthe sco disconnection is timeout. The sock will be deallocatedlater, but it is dereferenced again in sco_sock_timeout. As aresult, the use-after-free bugs will happen. The root cause isshown below: Cleanup Thread | Worker Threadsco_sock_release | sco_sock_close | __sco_sock_close | sco_sock_set_timer | schedule_delayed_work | sco_sock_kill | (wait a time) sock_put(sk) //FREE | sco_sock_timeout | sock_hold(sk) //USEThe KASAN report triggered by POC is shown below:[ 95.890016] ==================================================================[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7...[ 95.890755] Workqueue: events sco_sock_timeout[ 95.890755] Call Trace:[ 95.890755] [ 95.890755] dump_stack_lvl+0x45/0x110[ 95.890755] print_address_description+0x78/0x390[ 95.890755] print_report+0x11b/0x250[ 95.890755] ? __virt_addr_valid+0xbe/0xf0[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0[ 95.890755] kasan_report+0x139/0x170[ 95.890755] ? update_load_avg+0xe5/0x9f0[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0[ 95.890755] kasan_check_range+0x2c3/0x2e0[ 95.890755] sco_sock_timeout+0x5e/0x1c0[ 95.890755] process_one_work+0x561/0xc50[ 95.890755] worker_thread+0xab2/0x13c0[ 95.890755] ? pr_cont_work+0x490/0x490[ 95.890755] kthread+0x279/0x300[ 95.890755] ? pr_cont_work+0x490/0x490[ 95.890755] ? kthread_blkcg+0xa0/0xa0[ 95.890755] ret_from_fork+0x34/0x60[ 95.890755] ? kthread_blkcg+0xa0/0xa0[ 95.890755] ret_from_fork_asm+0x11/0x20[ 95.890755] [ 95.890755][ 95.890755] Allocated by task 506:[ 95.890755] kasan_save_track+0x3f/0x70[ 95.890755] __kasan_kmalloc+0x86/0x90[ 95.890755] __kmalloc+0x17f/0x360[ 95.890755] sk_prot_alloc+0xe1/0x1a0[ 95.890755] sk_alloc+0x31/0x4e0[ 95.890755] bt_sock_alloc+0x2b/0x2a0[ 95.890755] sco_sock_create+0xad/0x320[ 95.890755] bt_sock_create+0x145/0x320[ 95.890755] __sock_create+0x2e1/0x650[ 95.890755] __sys_socket+0xd0/0x280[ 95.890755] __x64_sys_socket+0x75/0x80[ 95.890755] do_syscall_64+0xc4/0x1b0[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f[ 95.890755][ 95.890755] Freed by task 506:[ 95.890755] kasan_save_track+0x3f/0x70[ 95.890755] kasan_save_free_info+0x40/0x50[ 95.890755] poison_slab_object+0x118/0x180[ 95.890755] __kasan_slab_free+0x12/0x30[ 95.890755] kfree+0xb2/0x240[ 95.890755] __sk_destruct+0x317/0x410[ 95.890755] sco_sock_release+0x232/0x280[ 95.890755] sock_close+0xb2/0x210[ 95.890755] __fput+0x37f/0x770[ 95.890755] task_work_run+0x1ae/0x210[ 95.890755] get_signal+0xe17/0xf70[ 95.890755] arch_do_signal_or_restart+0x3f/0x520[ 95.890755] syscall_exit_to_user_mode+0x55/0x120[ 95.890755] do_syscall_64+0xd1/0x1b0[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f[ 95.890755][ 95.890755] The buggy address belongs to the object at ffff88800c388000[ 95.890755] which belongs to the cache kmalloc-1k of size 1024[ 95.890755] The buggy address is located 128 bytes inside of[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)[ 95.890755][ 95.890755] The buggy address belongs to the physical page:[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0[ 95.890755] ano---truncated---
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- cups-libs < 1.7.5-20.49.1 (version in image is 1.7.5-20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changesWhen moving a station out of a VLAN and deleting the VLAN afterwards, thefast_rx entry still holds a pointer to the VLAN's netdev, which can causeuse-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rxafter the VLAN change.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_is_network_name_deleted()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in is_valid_oplock_break()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_is_valid_lease_break()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in cifs_stats_proc_show()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: Fix use-after-free on a dentry's dname.name->d_name.name can change on rename and the earlier value can be freed;there are conditions sufficient to stabilize it (->d_lock on dentry,->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,rename_lock), but none of those are met at any of the sites. Take a stablesnapshot of the name instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: Clear napi->skb before dev_kfree_skb_any()gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after itis freed with dev_kfree_skb_any(). This can result in a subsequent callto napi_get_frags returning a dangling pointer.Fix this by clearing napi->skb before the skb is freed.
Packages affected:
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix uninit-value in copy_name[syzbot reported]BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[Fix]When allocating memory to strbuf, initialize memory to 0.
Packages affected:
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Serialise kcm_sendmsg() for the same socket.syzkaller reported UAF in kcm_release(). [0]The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees skb that is already in the write queue 5. kcm_release() does double-free the skb in the write queueWhen a thread is building a MSG_MORE skb, another thread must not touch it.Let's add a per-sk mutex and serialise kcm_sendmsg().[0]:BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent UAF in ip6_send_skb()syzbot reported an UAF in ip6_send_skb() [1]After ip6_local_out() has returned, we no longer can safelydereference rt, unless we hold rcu_read_lock().A similar issue has been fixed in commita688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")Another potential issue in ip6_finish_output2() is handled in aseparate patch.[1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f936bf79e79Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check link_index before accessing dc->links[][WHY & HOW]dc->links[] has max size of MAX_LINKS and NULL is return when trying toaccess with out-of-bound index.This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links[Why]Coverity report OVERRUN warning. There areonly max_links elements within dc->links. linkcount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.[How]Make sure link count less than max_links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check gpio_id before used as array index[WHY & HOW]GPIO_ID_UNKNOWN (-1) is not a valid value for array index and thereforeshould be checked in advance.This fixes 5 OVERRUN issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: sysfs: validate return type of _STR methodOnly buffer objects are valid return values of _STR.If something else is returned description_show() will access invalidmemory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointerPass pointer reference to amdgpu_bo_unref to clear the correct pointer,otherwise amdgpu_bo_unref clear the local variable, the original pointernot set to NULL, this could cause use-after-free bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in async decryptionDoing an async decryption (large read) crashes with aslab-use-after-free way down in the crypto API.Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]This is because TFM is being used in parallel.Fix this by allocating a new AEAD TFM for async decryption, but keepthe existing one for synchronous READ cases (similar to what is donein smb3_calc_signature()).Also remove the calls to aead_request_set_callback() andcrypto_wait_req() since it's always going to be a synchronous operation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Initialization of the dangling pointer occurring in vsk->transDuring loopback communication, a dangling pointer can be created invsk->trans, potentially leading to a Use-After-Free condition. Thisissue is resolved by initializing vsk->trans to NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: io_edgeport: fix use after free in debug printkThe "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb)is a use after free of the "urb" pointer. Store the "dev" pointer at thestart of the function to avoid this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: zero-initialize the report bufferSince the report buffer is used by all kinds of drivers in various ways, let'szero-initialize it during allocation to make sure that it can't be ever usedto leak kernel memory via specially-crafted report.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOTIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumedto be either root or ingress. This assumption is bogus since it's validto create egress qdiscs with major handle ffff:Budimir Markovic found that for qdiscs like DRR that maintain an activeclass list, it will cause a UAF with a dangling class pointer.In 066a3b5b2346, the concern was to avoid iterating over the ingressqdisc since its parent is itself. The proper fix is to stop when parentTC_H_ROOT is reached because the only way to retrieve ingress is when ahierarchy which does not contain a ffff: major handle call intoqdisc_lookup with TC_H_MAJ(TC_H_ROOT).In the scenario where major ffff: is an egress qdisc in any of the treelevels, the updates will also propagate to TC_H_ROOT, which then theiteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-jpeg: prevent buffer overflowsThe current logic allows word to be less than 2. If this happens,there will be buffer overflows, as reported by smatch. Add extrachecks to prevent it.While here, remove an unused word = 0 assignment.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_formatThis can lead to out of bounds writes since frames of this type were nottaken into account when calculating the size of the frames buffer inuvc_parse_streaming.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: add missing range check in bitmap_ip_uadtWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,the values of ip and ip_to are slightly swapped. Therefore, the range checkfor ip should be done later, but this part is missing and it seems that thevulnerability occurs.So we should add missing range checks and remove unnecessary range checks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent a potential integer overflowIf the tag length is >= U32_MAX - 3 then the "length + 4" additioncan result in an integer overflow. Address this by splitting thedecoding into several steps so that decode_cb_compound4res() doesnot have to perform arithmetic on the unsafe length value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ...Since this bug has been confirmed to be caused by insufficient verificationof conn_rsp_epid, I think it would be appropriate to add a range check forconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp's timer handler function causes problems.To fix this problem, let's hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the 'NextCapability Offset' field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: 6fire: Release resources at card releaseThe current 6fire code tries to release the resources right after thecall of usb6fire_chip_abort(). But at this moment, the card objectmight be still in use (as we're calling snd_card_free_when_closed()).For avoid potential UAFs, move the release of resources to the card'sprivate_free instead of the manual call of usb6fire_chip_destroy() atthe USB disconnect callback.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: xsltGetInheritedNsList in libxslt before 1.1.43 has a use-after-free issue related to exclusion of result prefixes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxslt1 < 1.1.28-17.18.1 (version in image is 1.1.28-17.15.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet6: do not leave a dangling sk pointer in inet6_create()sock_init_data() attaches the allocated sk pointer to the provided sockobject. If inet6_create() fails later, the sk object is released, but thesock object retains the dangling sk pointer, which may cause use-after-freelater.Clear the sock sk pointer on error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: inet: do not leave a dangling sk pointer in inet_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If inet_create() fails later, the sk object is freed, but thesock object retains the dangling pointer, which may create use-after-freelater.Clear the sk pointer in the sock object on error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()bt_sock_alloc() attaches allocated sk object to the provided sock object.If rfcomm_dlc_alloc() fails, we release the sk object, but leave thedangling pointer in the sock object, which may cause use-after-free.Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()bt_sock_alloc() allocates the sk object and attaches it to the providedsock object. On error l2cap_sock_alloc() frees the sk object, but thedangling pointer is still attached to the sock object, which may createuse-after-free in other code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix LED ID check in led_tg_check()Syzbot has reported the following BUG detected by KASAN:BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70Read of size 1 at addr ffff8881022da0c8 by task repro/5879...Call Trace: dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... Since an invalid (without '\0' byte at all) byte sequence may be passedfrom userspace, add an extra check to ensure that such a sequence isrejected as possible ID and so never passed to 'kstrdup()' and further.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: defer final 'struct net' free in netns dismantleIlya reported a slab-use-after-free in dst_destroy [1]Issue is in xfrm6_net_init() and xfrm4_net_init() :They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops.But net structure might be freed before all the dst callbacks arecalled. So when dst_destroy() calls later :if (dst->ops->destroy) dst->ops->destroy(dst);dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed.See a relevant issue fixed in :ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")A fix is to queue the 'struct net' to be freed after oneanother cleanup_net() round (and existing rcu_barrier())[1]BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0Dec 03 05:46:18 kernel:CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:124)print_address_description.constprop.0 (mm/kasan/report.c:378)? dst_destroy (net/core/dst.c:112)print_report (mm/kasan/report.c:489)? dst_destroy (net/core/dst.c:112)? kasan_addr_to_slab (mm/kasan/common.c:37)kasan_report (mm/kasan/report.c:603)? dst_destroy (net/core/dst.c:112)? rcu_do_batch (kernel/rcu/tree.c:2567)dst_destroy (net/core/dst.c:112)rcu_do_batch (kernel/rcu/tree.c:2567)? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)rcu_core (kernel/rcu/tree.c:2825)handle_softirqs (kernel/softirq.c:554)__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)irq_exit_rcu (kernel/softirq.c:651)sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835dR10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)? cpuidle_idle_call (kernel/sched/idle.c:186)default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)cpuidle_idle_call (kernel/sched/idle.c:186)? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)do_idle (kernel/sched/idle.c:326)cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452)common_startup_64 (arch/x86/kernel/head_64.S:414) Dec 03 05:46:18 kernel:Allocated by task 12184:kasan_save_stack (mm/kasan/common.c:48)kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)create_new_namespaces---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/cpum_sf: Handle CPU hotplug remove during samplingCPU hotplug remove handling triggers the following functioncall sequence: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu()The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers()This function de-allocates all sampling data buffers (SDBs) allocatedfor that CPU at event initialization. It also clears thePMU_F_RESERVED bit. The CPU is gone and can not be sampled.With the event still being active on the removed CPU, the CPU eventhotplug support in kernel performance subsystem triggers thefollowing function calls on the removed CPU: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update()to stop and remove the event. During removal of the event, thesampling device driver tries to read out the remaining samples fromthe sample data buffers (SDBs). But they have already been freed(and may have been re-assigned). This may lead to a use after freesituation in which case the samples are most likely invalid. In thebest case the memory has not been reassigned and still containsvalid data.Remedy this situation and check if the CPU is still in reservedstate (bit PMU_F_RESERVED set). In this case the SDBs have not beenreleased an contain valid data. This is always the case whenthe event is removed (and no CPU hotplug off occured).If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: don't allow 1 packet limitThe current implementation does not work correctly with a limit of1. iproute2 actually checks for this and this patch adds the check inkernel as well.This fixes the following syzkaller reported crash:UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6index 65535 is out of range for type 'struct sfq_head[128]'CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcbRIP: 0033:0x7fe5e7b52479Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270The crash can be also be reproduced with the following (with a tcrecompiled to allow for sfq limits of 1):tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1ifconfig dummy0 upping -I dummy0 -f -c2 -W0.1 8.8.8.8sleep 1Scenario that triggers the crash:* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1* TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later.* the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL.At this point, assuming no more packets are queued, when sch_dequeueruns again it will decrement the qlen for the current empty slotcausing an underflow and the subsequent out of bounds access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN()instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access.Compile tested only.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pfifo_tail_enqueue: Drop new packet when sch->limit == 0Expected behaviour:In case we reach scheduler's limit, pfifo_tail_enqueue() will drop apacket in scheduler's queue and decrease scheduler's qlen by one.Then, pfifo_tail_enqueue() enqueue new packet and increasescheduler's qlen by one. Finally, pfifo_tail_enqueue() return`NET_XMIT_CN` status code.Weird behaviour:In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on ascheduler that has no packet, the 'drop a packet' step will do nothing.This means the scheduler's qlen still has value equal 0.Then, we continue to enqueue new packet and increase scheduler's qlen byone. In summary, we can leverage pfifo_tail_enqueue() to increase qlen byone and return `NET_XMIT_CN` status code.The problem is:Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1.Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem.This violate the design where parent's qlen should equal to the sum of its childrens'qlen.Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()qdisc_tree_reduce_backlog() notifies parent qdisc only if childqdisc becomes empty, therefore we need to reduce the backlog of thechild qdisc before calling it. Otherwise it would miss the opportunityto call cops->qlen_notify(), in the case of DRR, it resulted in UAFsince DRR uses ->qlen_notify() to maintain its active list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo arrayThe loop that detects/populates cache information already has a boundscheck on the array size but does not account for cache levels withseparate data/instructions cache. Fix this by incrementing the indexfor any populated leaf (instead of any populated level).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vrf: use RCU protection in l3mdev_l3_out()l3mdev_l3_out() can be called without RCU being held:raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()Add rcu_read_lock() / rcu_read_unlock() pair to avoida potential UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Prevent creation of classes with TC_H_ROOTThe function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a terminationcondition when traversing up the qdisc tree to update parent backlogcounters. However, if a class is created with classid TC_H_ROOT, thetraversal terminates prematurely at this class instead of reaching theactual root qdisc, causing parent statistics to be incorrectly maintained.In case of DRR, this could lead to a crash as reported by Mingi Cho.Prevent the creation of any Qdisc class with classid TC_H_ROOT(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: numbers.c in libxslt before 1.1.43 has a use-after-free because, in nested XPath evaluations, an XPath context node can be modified but never restored. This is related to xsltNumberFormatGetValue, xsltEvalXPathPredicate, xsltEvalXPathStringNs, and xsltComputeSortResultInternal.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxslt1 < 1.1.28-17.18.1 (version in image is 1.1.28-17.15.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: hfsc: Fix a UAF vulnerability in class handlingThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc classhandling. The issue occurs due to a time-of-check/time-of-use conditionin hfsc_change_class() when working with certain child qdiscs like netemor codel.The vulnerability works as follows:1. hfsc_change_class() checks if a class has packets (q.qlen != 0)2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue3. The code continues assuming the queue is still non-empty, adding the class to vttree4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree5. Later, when the class is destroyed, this can lead to a Use-After-FreeThe fix adds a second queue length check after qdisc_peek_len() to verifythe queue wasn't emptied.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()After making all ->qlen_notify() callbacks idempotent, now it is safe toremove the check of qlen!=0 from both fq_codel_dequeue() andcodel_qdisc_dequeue().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: prio: fix a race in prio_tune()Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atm: fix /proc/net/atm/lec handling/proc/net/atm/lec must ensure safety against dev_lec[] changes.It appears it had dev_put() calls without prior dev_hold(),leading to imbalance and UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipc: fix to protect IPCS lookups using RCUsyzbot reported that it discovered a use-after-free vulnerability, [0][0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/idr_for_each() is protected by rwsem, but this is not enough. If it isnot protected by RCU read-critical region, when idr_for_each() callsradix_tree_node_free() through call_rcu() to free the radix_tree_nodestructure, the node will be freed immediately, and when reading the nextnode in radix_tree_for_each_slot(), the already freed memory may be read.Therefore, we need to add code to make sure that idr_for_each() isprotected within the RCU read-critical region when we call it inshm_destroy_orphaned().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in crypt_message when using async cryptoThe CVE-2024-50047 fix removed asynchronous crypto handling fromcrypt_message(), assuming all crypto operations are synchronous.However, when hardware crypto accelerators are used, this can causeuse-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...);Hardware crypto modules often implement async AEAD operations forperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,the operation completes asynchronously. Without crypto_wait_req(),the function immediately frees the request buffer, leading to crasheswhen the driver later accesses the freed memory.This results in a use-after-free condition when the hardware cryptodriver later accesses the freed request structure, leading to kernelcrashes with NULL pointer dereferences.The issue occurs because crypto_alloc_aead() with mask=0 doesn'tguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC inthe mask, async implementations can be selected.Fix by restoring the async crypto handling:- DECLARE_CRYPTO_WAIT(wait) for completion tracking- aead_request_set_callback() for async completion notification- crypto_wait_req() to wait for operation completionThis ensures the request buffer isn't freed until the crypto operationcompletes, whether synchronous or asynchronous, while preserving theCVE-2024-50047 fix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: do not bypass hid_hw_raw_requesthid_hw_raw_request() is actually useful to ensure the provided bufferand length are valid. Directly calling in the low level transport driverfunction bypassed those checks and allowed invalid paramto be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: ensure the allocated report buffer can contain the reserved report IDWhen the report ID is not used, the low level transport drivers expectthe first byte to be 0. However, currently the allocated buffer notaccount for that extra byte, meaning that instead of having 8 guaranteedbytes for implement to be working, we only have 7.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().smc_clc_prfx_set() is called during connect() and not under RCUnor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()after kernel_getsockname().Note that the returned value of smc_clc_prfx_set() is not usedin the caller.While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()not to touch dst there.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- tar > 0-0 (version in image is 1.27.1-15.21.1).
-
Description: A flaw was found in libxslt where the attribute type, atype, flags are modified in a way that corrupts internal memory management. When XSLT functions, such as the key() process, result in tree fragments, this corruption prevents the proper cleanup of ID attributes. As a result, the system may access freed memory, causing crashes or enabling attackers to trigger heap corruption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.90.1 (version in image is 2.9.4-46.65.1).
-
Description: getchar.c in Vim before 8.1.1365 and Neovim before 0.3.6 allows remote attackers to execute arbitrary OS commands via the :source! command in a modeline, as demonstrated by execute in Vim, and assert_fails or nvim_input in Neovim.
Packages affected:
- vim-data-common > 0-0 (version in image is 9.0.1894-17.23.2).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:aoe: fix the potential use-after-free problem in aoecmd_cfg_pktsThis patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initialcode is finished. But the net_device ifp will still be used inlater tx()->dev_queue_xmit() in kthread. Which means that thedev_put(ifp) should NOT be called in the success path of skbinitial code in aoecmd_cfg_pkts(). Otherwise tx() may run intouse-after-free because the net_device is freed.This patch removed the dev_put(ifp) in the success path inaoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools < 2.48.2-12.52.1 (version in image is 2.48.2-12.34.1).
-
Description: There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsqlite3-0 < 3.50.2-9.41.1 (version in image is 3.39.3-9.26.1).
-
Description: nscd: Stack-based buffer overflow in netgroup cacheIf the Name Service Cache Daemon's (nscd) fixed size cache is exhaustedby client requests then a subsequent client request for netgroup datamay result in a stack-based buffer overflow. This flaw was introducedin glibc 2.15 when the cache was added to nscd.This vulnerability is only present in the nscd binary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc < 2.22-114.34.1 (version in image is 2.22-114.31.1).
-
Description: A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, miscalculates DW_FORM_ref_addr die refs in the case of a relocatable object file, which allows remote attackers to cause a denial of service (find_abstract_instance_name invalid memory read, segmentation fault, and application crash).
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- openssl > 0-0 (version in image is 1.0.2p-1.13).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: fix stack OOB read while fragmenting IPv4 packetsrunning openvswitch on kernels built with KASAN, it's possible to see thefollowing splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked()the pointer to struct dst_entry is used as pointer to struct rtable: thisturns the access to struct members like rt_mtu_locked into an OOB read inthe stack. Fix this changing the temporary variable used for IPv4 packetsin ovs_fragment(), similarly to what is done for IPv6 few lines below.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation.
Packages affected:
- kernel-default < 4.12.14-122.183.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The DNS message parsing code in `named` includes a section whose computational complexity is overly high. It does not cause problems for typical DNS traffic, but crafted queries and responses may cause excessive CPU load on the affected `named` instance by exploiting this flaw. This issue affects both authoritative servers and recursive resolvers.This issue affects BIND 9 versions 9.0.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils < 9.11.22-3.52.1 (version in image is 9.11.22-3.49.1).
-
Description: The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.
Packages affected:
- libnghttp2-14 < 1.39.2-3.13.1 (version in image is 1.39.2-3.10.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils < 9.11.22-3.52.1 (version in image is 9.11.22-3.49.1).
-
Description: The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils < 9.11.22-3.52.1 (version in image is 9.11.22-3.49.1).
-
Description: The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.
Packages affected:
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix session state check in reconnect to avoid use-after-free issueDon't collect exiting session in smb2_reconnect_server(), because itwill be released soon.Note that the exiting session will stay in server->smb_ses_list untilit complete the cifs_free_ipc() and logoff() and then delete itselffrom the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils < 9.11.22-3.60.2 (version in image is 9.11.22-3.49.1).
-
Description: A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libtasn1 < 4.9-3.16.1 (version in image is 4.9-3.13.1).
-
Description: Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils < 9.11.22-3.57.1 (version in image is 9.11.22-3.49.1).
-
Description: If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils > 0-0 (version in image is 9.11.22-3.49.1).
-
Description: An issue was discovered in libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.
Packages affected:
- libxml2-2 < 2.9.4-46.71.1 (version in image is 2.9.4-46.65.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 < 1.16.3-46.6.1 (version in image is 1.12.5-40.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: pass correct message length to ip6_append_datal2tp_ip6_sendmsg needs to avoid accounting for the transport headertwice when splicing more data into an already partially-occupied skbuff.To manage this, we check whether the skbuff contains data usingskb_queue_empty when deciding how much data to append usingip6_append_data.However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;...due to C operator precedence, this ends up setting ulen totranshdrlen for messages with a non-zero length, which results incorrupted packets on the wire.Add parentheses to correct the calculation in line with the originalintent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync. This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libnghttp2-14 < 1.39.2-3.18.1 (version in image is 1.39.2-3.10.1).
-
Description: nscd: Null pointer crashes after notfound responseIf the Name Service Cache Daemon's (nscd) cache fails to add a not-foundnetgroup response to the cache, the client request can result in a nullpointer dereference. This flaw was introduced in glibc 2.15 when thecache was added to nscd.This vulnerability is only present in the nscd binary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc < 2.22-114.34.1 (version in image is 2.22-114.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/core: Implement a limit on UMAD receive ListThe existing behavior of ib_umad, which maintains received MADpackets in an unbounded list, poses a risk of uncontrolled growth.As user-space applications extract packets from this list, the rateof extraction may not match the rate of incoming packets, leadingto potential list overflow.To address this, we introduce a limit to the size of the list. Afterconsidering typical scenarios, such as OpenSM processing, which canhandle approximately 100k packets per second, and the 1-second retrytimeout for most packets, we set the list size limit to 200k. Packetsreceived beyond this limit are dropped, assuming they are likely timedout by the time they are handled by user-space.Notably, packets queued on the receive list due to reasons liketimed-out sends are preserved even when the list is full.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: fix memory leak for not ip packetsFree the unused skb when not ip packets arrive.
Packages affected:
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: check skb is non-NULL in tcp_rto_delta_us()We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generickernel that are running ceph and recently hit a null ptr dereference intcp_rearm_rto(). Initially hitting it from the TLP path, but then later we alsosaw it getting hit from the RACK case as well. Here are examples of the oopsmessages we saw in each of those cases:Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel modeJul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present pageJul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTIJul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-UbuntuJul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554Jul 26 15:05:02 rx [11061395.916786] Call Trace:Jul 26 15:05:02 rx [11061395.919488]Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1fJul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check return value of sock_recvmsg when draining clc dataWhen receiving clc msg, the field length in smc_clc_msg_hdr indicates thelength of msg should be received from network and the value should not befully trusted as it is from the network. Once the value of length exceedsthe value of buflen in function smc_clc_wait_msg it may run into deadloopwhen trying to drain the remaining data exceeding buflen.This patch checks the return value of sock_recvmsg when draining data incase of deadloop in draining.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: There is a MEDIUM severity vulnerability affecting CPython.Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.139.1 (version in image is 3.4.10-25.116.1).
-
Description: There is a MEDIUM severity vulnerability affecting CPython.The email module didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized.
Packages affected:
- libpython3_4m1_0 < 3.4.10-25.136.1 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat < 2.7.1-21.43.1 (version in image is 2.1.0-21.28.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
-
Description: A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxslt1 < 1.1.28-17.21.1 (version in image is 1.1.28-17.15.1).
-
Description: An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent < 20250116.00-1.47.2 (version in image is 20230601.00-1.32.3).
-
Description: SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent > 0-0 (version in image is 20230601.00-1.32.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().syzkaller reported a null-ptr-deref in sock_omalloc() while allocatinga CALIPSO option. [0]The NULL is of struct sock, which was fetched by sk_to_full_sk() incalipso_req_setattr().Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),reqsk->rsk_listener could be NULL when SYN Cookie is returned to itsclient, as hinted by the leading SYN Cookie log.Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookiefor CALIPSO. 3) is also no go as there have been many efforts to reduceatomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35("tcp/dccp: do not touch listener sk_refcnt under synflood").As of the blamed commit, SYN Cookie already did not need refcounting,and no one has stumbled on the bug for 9 years, so no CALIPSO user willcare about SYN Cookie.Let's return an error in calipso_req_setattr() and calipso_req_delattr()in the SYN Cookie case.This can be reproduced by [1] on Fedora and now connect() of nc times out.[0]:TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]RIP: 0010:sock_net include/net/sock.h:655 [inline]RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8bRSP: 0018:ffff88811af89038 EFLAGS: 00010216RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640eR10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0PKRU: 80000000Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netf---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Prevent VMA split of buffer mappingsThe perf mmap code is careful about mmap()'ing the user page with theringbuffer and additionally the auxiliary buffer, when the event supportsit. Once the first mapping is established, subsequent mapping have to usethe same offset and the same size in both cases. The reference counting forthe ringbuffer and the auxiliary buffer depends on this being correct.Though perf does not prevent that a related mapping is split via mmap(2),munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,which take reference counts, but then the subsequent perf_mmap_close()calls are not longer fulfilling the offset and size checks. This leads toreference count leaks.As perf already has the requirement for subsequent mappings to match theinitial mapping, the obvious consequence is that VMA splits, caused byresizing of a mapping or partial unmapping, have to be prevented.Implement the vm_operations_struct::may_split() callback and returnunconditionally -EINVAL.That ensures that the mapping offsets and sizes cannot be changed after thefact. Remapping to a different fixed address with the same size is stillpossible as it takes the references for the new mapping and drops those ofthe old mapping.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-setuptools < 40.6.2-4.27.1 (version in image is 40.6.2-4.21.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- cups-libs < 1.7.5-20.54.1 (version in image is 1.7.5-20.46.1).
-
Description: libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat < 2.7.1-21.46.1 (version in image is 2.1.0-21.28.1).
-
Description: A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.87.1 (version in image is 2.9.4-46.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix ipv4 null-ptr-deref in route error pathThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()without ensuring skb->dev is set, leading to a NULL pointer dereferencein fib_compute_spec_dst() when ipv4_link_failure() attempts to sendICMP destination unreachable messages.The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip optionsin ipv4_link_failure") started calling __ip_options_compile() fromipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()which dereferences skb->dev. An attempt was made to fix the NULL skb->devdereference in commit 0113d9c9d1cc ("ipv4: fix null-deref inipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)dereference by using a fallback device. The fix was incomplete becausefib_compute_spec_dst() later in the call chain still accesses skb->devdirectly, which remains NULL when IPVS calls dst_link_failure().The crash occurs when:1. IPVS processes a packet in NAT mode with a misconfigured destination2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route3. The error path calls dst_link_failure(skb) with skb->dev == NULL4. ipv4_link_failure() -> ipv4_send_dest_unreach() -> __ip_options_compile() -> fib_compute_spec_dst()5. fib_compute_spec_dst() dereferences NULL skb->devApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fixipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev beforecalling dst_link_failure().KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285Call Trace: spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()There exists a kernel oops caused by a BUG_ON(nhead < 0) atnet/core/skbuff.c:2232 in pskb_expand_head().This bug is triggered as part of the calipso_skbuff_setattr()routine when skb_cow() is passed headroom > INT_MAX(i.e. (int)(skb_headroom(skb) + len_delta) < 0).The root cause of the bug is due to an implicit integer cast in__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensurethat delta = headroom - skb_headroom(skb) is never negative, otherwisewe will trigger a BUG_ON in pskb_expand_head(). However, ifheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, deltabecomes negative, and pskb_expand_head() is passed a negative value fornhead.Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()by only using skb_cow() to grow headroom.PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verfA zero length gss_token results in pages == 0 and in_token->pages[0]is NULL. The code unconditionally evaluatespage_address(in_token->pages[0]) for the initial memcpy, which candereference NULL even when the copy length is 0. Guard the firstmemcpy so it only runs when length > 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: 1. A cookie is set using the `secure` keyword for `https://target` 2. curl is redirected to or otherwise made to speak with `http://target` (same hostname, but using clear text HTTP) using the same cookie set 3. The same cookie name is set - but with just a slash as path (`path=\"/\",`). Since this site is not secure, the cookie *should* just be ignored.4. A bug in the path comparison logic makes curl read outside a heap buffer boundaryThe bug either causes a crash or it potentially makes the comparison come tothe wrong conclusion and lets the clear-text site override the contents of thesecure cookie, contrary to expectations and depending on the memory contentsimmediately following the single-byte allocation that holds the path.The presumed and correct behavior would be to plainly ignore the second set ofthe cookie since it was already set as secure on a secure host so overridingit on an insecure host should not be okay.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.108.1 (version in image is 8.0.1-11.74.1).
-
Description: Issue summary: An application trying to decrypt CMS messages encrypted usingpassword based encryption can trigger an out-of-bounds read and write.Impact summary: This out-of-bounds read may trigger a crash which leads toDenial of Service for an application. The out-of-bounds write can causea memory corruption which can have various consequences includinga Denial of Service or Execution of attacker-supplied code.Although the consequences of a successful exploit of this vulnerabilitycould be severe, the probability that the attacker would be able toperform it is low. Besides, password based (PWRI) encryption support in CMSmessages is very rarely used. For that reason the issue was assessed asModerate severity according to our Security Policy.The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by thisissue, as the CMS implementation is outside the OpenSSL FIPS moduleboundary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libopenssl1_0_0 < 1.0.2p-3.98.1 (version in image is 1.0.2p-3.84.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.2, a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. This vulnerability is fixed in 0.6.2.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-pyasn1 > 0-0 (version in image is 0.1.9-4.6.1).
-
Description: An exploitable denial-of-service vulnerability exists in the X509 certificate parser of Python.org Python 2.7.11 / 3.6.6. A specially crafted X509 certificate can cause a NULL pointer dereference, resulting in a denial of service. An attacker can initiate or accept TLS connections using crafted certificates to trigger this vulnerability.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Python 2.7.x through 2.7.16 and 3.x through 3.7.2 is affected by: Improper Handling of Unicode Encoding (with an incorrect netloc) during NFKC normalization. The impact is: Information disclosure (credentials, cookies, etc. that are cached against a given hostname). The components are: urllib.parse.urlsplit, urllib.parse.urlparse. The attack vector is: A specially crafted URL could be incorrectly parsed to locate cookies or authentication data and send that information to a different host than when parsed correctly. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.7, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.3, v3.7.3rc1, v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The log_config_command function in ntp_parser.y in ntpd in NTP before 4.2.7p42 allows remote attackers to cause a denial of service (ntpd crash) via crafted logconfig commands.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- ntp > 0-0 (version in image is 4.2.8p17-103.1).
-
Description: ntp_openssl.m4 in ntpd in NTP before 4.2.7p112 allows remote attackers to cause a denial of service (segmentation fault) via a crafted statistics or filegen configuration command that is not enabled during compilation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- ntp > 0-0 (version in image is 4.2.8p17-103.1).
-
Description: Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 < 1.16.3-46.6.1 (version in image is 1.12.5-40.52.1).
-
Description: A use-after-free flaw was found in the Linux kernel's sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: xmlXIncludeAddNode in xinclude.c in libxml2 before 2.11.0 has a use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.78.1 (version in image is 2.9.4-46.65.1).
-
Description: An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.124.1 (version in image is 3.4.10-25.116.1).
-
Description: In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 < 1.16.3-46.15.1 (version in image is 1.12.5-40.52.1).
-
Description: A vulnerability was found in Ruby. The Ruby interpreter is vulnerable to the Marvin Attack. This attack allows the attacker to decrypt previously encrypted messages or forge signatures by exchanging a large number of messages with the vulnerable service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: base/logging.c in Nagios Core before 4.2.4 allows local users with access to an account in the nagios group to gain root privileges via a symlink attack on the log file. NOTE: this can be leveraged by remote attackers using CVE-2016-9565.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libzmq3 < 4.0.4-15.8.1 (version in image is 4.0.4-15.6.1).
-
Description: GNU gdb All versions is affected by: Buffer Overflow - Out of bound memory access. The impact is: Deny of Service, Memory Disclosure, and Possible Code Execution. The component is: The main gdb module. The attack vector is: Open an ELF for debugging. The fixed version is: Not fixed yet.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: use call_rcu to free endpointThis patch is to delay the endpoint free by calling call_rcu() to fixanother use-after-free issue in sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274This issue occurs when asoc is peeled off and the old sk is freed aftergetting it by asoc->base.sk and before calling lock_sock(sk).To prevent the sk free, as a holder of the sk, ep should be alive whencalling lock_sock(). This patch uses call_rcu() and moves sock_put andep free into sctp_endpoint_destroy_rcu(), so that it's safe to try tohold the ep under rcu_read_lock in sctp_transport_traverse_process().If sctp_endpoint_hold() returns true, it means this ep is still aliveand we have held it and can continue to dump it; If it returns false,it means this ep is dead and can be freed after rcu_read_unlock, andwe should skip it.In sctp_sock_dump(), after locking the sk, if this ep is different fromtsp->asoc->ep, it means during this dumping, this asoc was peeled offbefore calling lock_sock(), and the sk should be skipped; If this ep isthe same with tsp->asoc->ep, it means no peeloff happens on this asoc,and due to lock_sock, no peeloff will happen either until release_sock.Note that delaying endpoint free won't delay the port release, as theport release happens in sctp_endpoint_destroy() before calling call_rcu().Also, freeing endpoint by call_rcu() makes it safe to access the sk byasoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().Thanks Jones to bring this issue up.v1->v2: - improve the changelog. - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Bounds check struct nfc_target arraysWhile running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18)This appears to be a legitimate lack of bounds checking innci_add_new_protocol(). Add the missing checks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: cdg: allow tcp_cdg_release() to be called multiple timesApparently, mptcp is able to call tcp_disconnect() on an alreadydisconnected flow. This is generally fine, unless current congestioncontrol is CDG, because it might trigger a double-free [1]Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect()more resilient.[1]BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022Workqueue: events mptcp_workerCall Trace:__dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106print_address_description mm/kasan/report.c:317 [inline]print_report.cold+0x2ba/0x719 mm/kasan/report.c:433kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356kasan_slab_free include/linux/kasan.h:200 [inline]slab_free_hook mm/slub.c:1759 [inline]slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785slab_free mm/slub.c:3539 [inline]kfree+0xe2/0x580 mm/slub.c:4567tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145__mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline]mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627process_one_work+0x991/0x1610 kernel/workqueue.c:2289worker_thread+0x665/0x1080 kernel/workqueue.c:2436kthread+0x2e4/0x3a0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306Allocated by task 3671:kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38kasan_set_track mm/kasan/common.c:45 [inline]set_alloc_info mm/kasan/common.c:437 [inline]____kasan_kmalloc mm/kasan/common.c:516 [inline]____kasan_kmalloc mm/kasan/common.c:475 [inline]__kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525kmalloc_array include/linux/slab.h:640 [inline]kcalloc include/linux/slab.h:671 [inline]tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline]tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844__sys_setsockopt+0x2d6/0x690 net/socket.c:2252__do_sys_setsockopt net/socket.c:2263 [inline]__se_sys_setsockopt net/socket.c:2260 [inline]__x64_sys_setsockopt+0xba/0x150 net/socket.c:2260do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdFreed by task 16:kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38kasan_set_track+0x21/0x30 mm/kasan/common.c:45kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370____kasan_slab_free mm/kasan/common.c:367 [inline]____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329kasan_slab_free include/linux/kasan.h:200 [inline]slab_free_hook mm/slub.c:1759 [inline]slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785slab_free mm/slub.c:3539 [inline]kfree+0xe2/0x580 mm/slub.c:4567tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484NF_HOOK include/linux/netfilter.h:302 [inline]NF_HOOK include/linux/netfilter.h:296 [inline]ip6_input+0x9c/0xd---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix underflow in parse_server_interfaces()In this loop, we step through the buffer and after each item we checkif the size_left is greater than the minimum size we need. However,the problem is that "bytes_left" is type ssize_t while sizeof() is typesize_t. That means that because of type promotion, the comparison isdone as an unsigned and if we have negative bytes left the loopcontinues instead of ending.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Always pass notifications when child class becomes emptyCertain classful qdiscs may invoke their classes' dequeue handler on anenqueue operation. This may unexpectedly empty the child qdisc and thusmake an in-flight class passive via qlen_notify(). Most qdiscs do notexpect such behaviour at this point in time and may re-activate theclass eventually anyways which will lead to a use-after-free.The referenced fix commit attempted to fix this behavior for the HFSCcase by moving the backlog accounting around, though this turned out tobe incomplete since the parent's parent may run into the issue too.The following reproducer demonstrates this use-after-free: tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888Since backlog accounting issues leading to a use-after-frees on staleclass pointers is a recurring pattern at this point, this patch takesa different approach. Instead of trying to fix the accounting, the patchensures that qdisc_tree_reduce_backlog always calls qlen_notify whenthe child qdisc is empty. This solves the problem because deletion ofqdiscs always involves a call to qdisc_reset() and / orqdisc_purge_queue() which ultimately resets its qlen to 0 thus causingthe following qdisc_tree_reduce_backlog() to report to the parent. Notethat this may call qlen_notify on passive classes multiple times. Thisis not a problem after the recent patch series that made all theclassful qdiscs qlen_notify() handlers idempotent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/9p: only translate RWX permissions for plain 9P2000Garbage in plain 9P2000's perm bits is allowed through, which causes itto be able to set (among others) the suid bit. This was presumably notthe intent since the unix extended bits are handled explicitly andconditionally on .u.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memoryIgnore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn'tenforce 32-byte alignment of nCR3.In the absolute worst case scenario, failure to ignore bits 4:0 can resultin an out-of-bounds read, e.g. if the target page is at the end of amemslot, and the VMM isn't using guard pages.Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0.And the SDM's much more explicit: 4:0 IgnoredNote, KVM gets this right when loading PDPTRs, it's only the nSVM flowthat is broken.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found with the libssh API function ssh_scp_new() in versions before 0.9.3 and before 0.8.8. When the libssh SCP client connects to a server, the scp command, which includes a user-provided path, is executed on the server-side. In case the library is used in a way where users can influence the third parameter of the function, it would become possible for an attacker to inject arbitrary commands, leading to a compromise of the remote target.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111The bug was found during fuzzing. Stacktrace locates it inath5k_eeprom_convert_pcal_info_5111.When none of the curve is selected in the loop, idx can goup to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.pd = &chinfo[pier].pd_curves[idx];There are many OOB writes using pd later in the code. So Iadded a sanity check for idx. Checks for other loops involvingAR5K_EEPROM_N_PD_CURVES are not needed as the loop index is notused outside the loops.The patch is NOT tested with real device.The following is the fuzzing reportBUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]Write of size 1 at addr ffff8880174a4d60 by task modprobe/214CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 really_probe+0x209/0x5d0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix out-of-bounds read when setting HMAC data.The SRv6 layer allows defining HMAC data that can later be used to sign IPv6Segment Routing Headers. This configuration is realised via netlink throughfour attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN andSEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actuallength of the SECRET attribute, it is possible to provide invalid combinations(e.g., secret = "", secretlen = 64). This case is not checked in the code andwith an appropriately crafted netlink message, an out-of-bounds read of upto 64 bytes (max secret length) can occur past the skb end pointer and intoskb_shared_info:Breakpoint 1, seg6_genl_sethmac (skb=, info=) at net/ipv6/seg6.c:208208 memcpy(hinfo->secret, secret, slen);(gdb) bt #0 seg6_genl_sethmac (skb=, info=) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 , family=, family=) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 ) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 ) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=, msg=0xffffc90000ba7e48, len=) at net/netlink/af_netlink.c:1921...(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end$1 = 0xffff88800b1b76c0(gdb) p/x secret$2 = 0xffff88800b1b76c0(gdb) p slen$3 = 64 '@'The OOB data can then be read back from userspace by dumping HMAC state. Thiscommit fixes this by ensuring SECRETLEN cannot exceed the actual length ofSECRET.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: A remote code execution vulnerability was found in Shim. The Shim boot support trusts attacker-controlled values when parsing an HTTP response. This flaw allows an attacker to craft a specific malicious HTTP request, leading to a completely controlled out-of-bounds write primitive and complete system compromise. This flaw is only exploitable during the early boot phase, an attacker needs to perform a Man-in-the-Middle or compromise the boot server to be able to exploit this vulnerability successfully.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:reiserfs: Avoid touching renamed directory if parent does not changeThe VFS will not be locking moved directory if its parent does notchange. Change reiserfs rename code to avoid touching renamed directoryif its parent does not change as without locking that can corrupt thefilesystem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: core: delete incorrect free in pinctrl_enable()The "pctldev" struct is allocated in devm_pinctrl_register_and_init().It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),so freeing it in pinctrl_enable() will lead to a double free.The devm_pinctrl_dev_release() function frees the pindescs and destroysthe mutex as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tap: add missing verification for short frameThe cited commit missed to check against the validity of the frame lengthin the tap_get_user_xdp() path, which could cause a corrupted skb to besent downstack. Even before the skb is transmitted, thetap_get_user_xdp()-->skb_set_network_header() may assume the size is morethan ETH_HLEN. Once transmitted, this could either cause out-of-boundaccess beyond the actual length, or confuse the underlayer with incorrector inconsistent header length in the skb metadata.In the alternative path, tap_get_user() already prohibits short frame whichhas the length less than Ethernet header size from being transmitted.This is to drop any frame shorter than the Ethernet header size just likehow tap_get_user() does.CVE: CVE-2024-41090
Packages affected:
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-osconfig-agent < 20250416.02-1.41.1 (version in image is 20230706.02-1.23.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_sock_timeoutconn->sk maybe have been unlinked/freed while waiting for sco_conn_lockso this checks if the conn->sk is still valid by checking if it part ofsco_sk_list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx24116: prevent overflows on SNR calculusas reported by Coverity, if reading SNR registers fail, a negativenumber will be returned, causing an underflow when reading SNRregisters.Prevent that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:security/keys: fix slab-out-of-bounds in key_task_permissionKASAN reports an out of bounds read:BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410security/keys/permission.c:54Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793This issue was also reported by syzbot.It can be reproduced by following these steps(more details [1]):1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'.2. Reboot and add the keys obtained in step 1.The reproducer demonstrates how this issue happened:1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring.2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK.3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read.To fix this issue, one should jump to descend_to_node if the ptr is ashortcut, regardless of whether the node is root or not.[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/[jarkko: tweaked the commit message a bit to have an appropriate closes tag.]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing '\0' character.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools > 0-0 (version in image is 2.48.2-12.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvbdev: prevent the risk of out of memory accessThe dvbdev contains a static variable used to store dvb minors.The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is setor not. When not set, dvb_register_device() won't check forboundaries, as it will rely that a previous call todvb_register_adapter() would already be enforcing it.On a similar way, dvb_device_open() uses the assumptionthat the register functions already did the needed checks.This can be fragile if some device ends using differentcalls. This also generate warnings on static check analyserslike Coverity.So, add explicit guards to prevent potential risk of OOM issues.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free of kernel socket in cleanup_bearer().syzkaller reported a use-after-free of UDP kernel socketin cleanup_bearer() without repro. [0][1]When bearer_disable() calls tipc_udp_disable(), cleanupof the UDP kernel socket is deferred by work callingcleanup_bearer().tipc_exit_net() waits for such works to finish by checkingtipc_net(net)->wq_count. However, the work decrements thecount too early before releasing the kernel socket,unblocking cleanup_net() and resulting in use-after-free.Let's move the decrement after releasing the socket incleanup_bearer().[0]:ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830[1]:BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfaHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: events cleanup_bearer
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools < 2.48.2-12.52.1 (version in image is 2.48.2-12.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix geneve_opt length integer overflowstruct geneve_opt uses 5 bit length for each single option, whichmeans every vary size option should be smaller than 128 bytes.However, all current related Netlink policies cannot promise thislength condition and the attacker can exploit a exact 128-byte sizeoption to *fake* a zero length option and confuse the parsing logic,further achieve heap out-of-bounds read.One example crash log is like below:[ 3.905425] ==================================================================[ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0[ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177[ 3.906646][ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1[ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014[ 3.907784] Call Trace:[ 3.907925] [ 3.908048] dump_stack_lvl+0x44/0x5c[ 3.908258] print_report+0x184/0x4be[ 3.909151] kasan_report+0xc5/0x100[ 3.909539] kasan_check_range+0xf3/0x1a0[ 3.909794] memcpy+0x1f/0x60[ 3.909968] nla_put+0xa9/0xe0[ 3.910147] tunnel_key_dump+0x945/0xba0[ 3.911536] tcf_action_dump_1+0x1c1/0x340[ 3.912436] tcf_action_dump+0x101/0x180[ 3.912689] tcf_exts_dump+0x164/0x1e0[ 3.912905] fw_dump+0x18b/0x2d0[ 3.913483] tcf_fill_node+0x2ee/0x460[ 3.914778] tfilter_notify+0xf4/0x180[ 3.915208] tc_new_tfilter+0xd51/0x10d0[ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560[ 3.919118] netlink_rcv_skb+0xcd/0x200[ 3.919787] netlink_unicast+0x395/0x530[ 3.921032] netlink_sendmsg+0x3d0/0x6d0[ 3.921987] __sock_sendmsg+0x99/0xa0[ 3.922220] __sys_sendto+0x1b7/0x240[ 3.922682] __x64_sys_sendto+0x72/0x90[ 3.922906] do_syscall_64+0x5e/0x90[ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 3.924122] RIP: 0033:0x7e83eab84407[ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf[ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c[ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407[ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003[ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c[ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0[ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8Fix these issues by enforing correct length condition in relatedpolicies.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktlsWhen sending plaintext data, we initially calculated the correspondingciphertext length. However, if we later reduced the plaintext data lengthvia socket policy, we failed to recalculate the ciphertext length.This results in transmitting buffers containing uninitialized data duringciphertext transmission.This causes uninitialized bytes to be appended after a complete"Application Data" packet, leading to errors on the receiving end whenparsing TLS record.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success-the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.15.1 (version in image is 0.8.7-3.9.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpng16-16 < 1.6.8-15.12.1 (version in image is 1.6.8-15.5.2).
-
Description: Python 2.7.14 is vulnerable to a Heap-Buffer-Overflow as well as a Heap-Use-After-Free. Python versions prior to 2.7.14 may also be vulnerable and it appears that Python 2.7.17 and prior may also be vulnerable however this has not been confirmed. The vulnerability lies when multiply threads are handling large amounts of data. In both cases there is essentially a race condition that occurs. For the Heap-Buffer-Overflow, Thread 2 is creating the size for a buffer, but Thread1 is already writing to the buffer without knowing how much to write. So when a large amount of data is being processed, it is very easy to cause memory corruption using a Heap-Buffer-Overflow. As for the Use-After-Free, Thread3->Malloc->Thread1->Free's->Thread2-Re-uses-Free'd Memory. The PSRT has stated that this is not a security vulnerability due to the fact that the attacker must be able to run code, however in some situations, such as function as a service, this vulnerability can potentially be used by an attacker to violate a trust boundary, as such the DWF feels this issue deserves a CVE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
-
Description: SQLite before 3.25.3, when the FTS3 extension is enabled, encounters an integer overflow (and resultant buffer overflow) for FTS3 queries that occur after crafted changes to FTS3 shadow tables, allowing remote attackers to execute arbitrary code by leveraging the ability to run arbitrary SQL statements (such as in certain WebSQL use cases), aka Magellan.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sqlite3-tcl > 0-0 (version in image is 3.39.3-9.26.1).
-
Description: In ksh version 20120801, a flaw was found in the way it evaluates certain environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Services and applications that allow remote unauthenticated attackers to provide one of those environment variables could allow them to exploit this issue remotely.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- ksh < 93vu-19.3.2 (version in image is 93vu-18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet: fully convert sk->sk_rx_dst to RCU rulessyzbot reported various issues around early demux,one being included in this changelog [1]sk->sk_rx_dst is using RCU protection without clearlydocumenting it.And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv()are not following standard RCU rules.[a] dst_release(dst);[b] sk->sk_rx_dst = NULL;They look wrong because a delete operation of RCU protectedpointer is supposed to clear the pointer beforethe call_rcu()/synchronize_rcu() guarding actual memory freeing.In some cases indeed, dst could be freed before [b] is done.We could cheat by clearing sk_rx_dst before callingdst_release(), but this seems the right time to stickto standard RCU annotations and debugging facilities.[1]BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline]BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 dst_check include/net/dst.h:470 [inline] tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792 ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340 ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583 ip_sublist_rcv net/ipv4/ip_input.c:609 [inline] ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644 __netif_receive_skb_list_ptype net/core/dev.c:5508 [inline] __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556 __netif_receive_skb_list net/core/dev.c:5608 [inline] netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699 gro_normal_list net/core/dev.c:5853 [inline] gro_normal_list net/core/dev.c:5849 [inline] napi_complete_done+0x1f1/0x880 net/core/dev.c:6590 virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline] virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557 __napi_poll+0xaf/0x440 net/core/dev.c:7023 napi_poll net/core/dev.c:7090 [inline] net_rx_action+0x801/0xb40 net/core/dev.c:7177 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649 common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240 asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629RIP: 0033:0x7f5e972bfd57Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73RSP: 002b:00007fff8a413210 EFLAGS: 00000283RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019 Allocated by task 13: kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:434 [inline] __kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467 kasan_slab_alloc include/linux/kasan.h:259 [inline] slab_post_alloc_hook mm/slab.h:519 [inline] slab_alloc_node mm/slub.c:3234 [inline] slab_alloc mm/slub.c:3242 [inline] kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247 dst_alloc+0x146/0x1f0 net/core/dst.c:92 rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613 ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:234---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix use-after-free in gfs2_glock_shrink_scanThe GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() toremove the glock from the lru list in __gfs2_glock_put().On the shrink scan path, the same flag is cleared under lru_lock but becauseof cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on theput side can be made without deleting the glock from the lru list.Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) toensure correct behavior on both sides - clear GLF_LRU after list_del underlru_lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qcom/emac: fix UAF in emac_removeadpt is netdev private data and it cannot beused after free_netdev() call. Using adpt after free_netdev()can cause UAF bug. Fix it by moving free_netdev() at the end of thefunction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:watchdog: Fix possible use-after-free in wdt_startup()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/qeth: fix NULL deref in qeth_clear_working_pool_list()When qeth_set_online() calls qeth_clear_working_pool_list() to rollback after an error exit from qeth_hardsetup_card(), we are at risk ofaccessing card->qdio.in_q before it was allocated byqeth_alloc_qdio_queues() via qeth_mpc_initialize().qeth_clear_working_pool_list() then dereferences NULL, and by writing toqueue->bufs[i].pool_entry scribbles all over the CPU's lowcore.Resulting in a crash when those lowcore areas are used next (eg. onthe next machine-check interrupt).Such a scenario would typically happen when the device is first setonline and its queues aren't allocated yet. An early IO error or certainmisconfigs (eg. mismatched transport mode, bad portno) then cause us toerror out from qeth_hardsetup_card() with card->qdio.in_q still beingNULL.Fix it by checking the pointer for NULL before accessing it.Note that we also have (rare) paths inside qeth_mpc_initialize() wherea configuration change can cause us to free the existing queues,expecting that subsequent code will allocate them again. If we thenerror out before that re-allocation happens, the same bug occurs.Root-caused-by: Heiko Carstens
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: Fix possible double-free in regcache_rbtree_exit()In regcache_rbtree_insert_to_block(), when 'present' realloc failed,the 'blk' which is supposed to assign to 'rbnode->block' will be freed,so 'rbnode->block' points a freed memory, in the error handling path ofregcache_rbtree_init(), 'rbnode->block' will be freed again inregcache_rbtree_exit(), KASAN will report double-free as follows:BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390Call Trace: slab_free_freelist_hook+0x10d/0x240 kfree+0xce/0x390 regcache_rbtree_exit+0x15d/0x1a0 regcache_rbtree_init+0x224/0x2c0 regcache_init+0x88d/0x1310 __regmap_init+0x3151/0x4a80 __devm_regmap_init+0x7d/0x100 madera_spi_probe+0x10f/0x333 [madera_spi] spi_probe+0x183/0x210 really_probe+0x285/0xc30To fix this, moving up the assignment of rbnode->block to immediately afterthe reallocation has succeeded so that the data structure stays valid evenif the second reallocation fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix use-after-free due to delegation raceA delegation break could arrive as soon as we've called vfs_setlease. Adelegation break runs a callback which immediately (innfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If wethen exit nfs4_set_delegation without hashing the delegation, it will befreed as soon as the callback is done with it, without ever beingremoved from del_recall_lru.Symptoms show up later as use-after-free or list corruption warnings,usually in the laundromat thread.I suspect aba2072f4523 "nfsd: grant read delegations to clients holdingwrites" made this bug easier to hit, but I looked as far back as v3.0and it looks to me it already had the same problem. So I'm not surewhere the bug was introduced; it may have been there from the beginning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called andtmp->tx_cq will be freed on the error path of mlx4_en_copy_priv().After that mlx4_en_alloc_resources() is called and there is a dereferenceof &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead toa use after free problem on failure of mlx4_en_copy_priv().Fix this bug by adding a check of mlx4_en_copy_priv()This bug was found by a static analyzer. The analysis employsdifferential checking to identify inconsistent security operations(e.g., checks or kfrees) between two code paths and confirms that theinconsistent operations are not recovered in the current function orthe callers, so they constitute bugs.Note that, as a bug found by static analysis, it can be a falsepositive or hard to trigger. Multiple researchers have cross-reviewedthe bug.Builds with CONFIG_MLX4_EN=m show no new warnings,and our static analyzer no longer warns about this code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm btree remove: fix use after free in rebalance_children()Move dm_tm_unlock() after dm_tm_dec().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free flaw was found in the Linux kernel's Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: improve size validations for received domain recordsThe function tipc_mon_rcv() allows a node to receive and processdomain_record structs from peer nodes to track their views of thenetwork topology.This patch verifies that the number of members in a received domainrecord does not exceed the limit defined by MAX_MON_DOMAIN, somethingthat may otherwise lead to a stack overflow.tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), wherewe are reading a 32 bit message data length field into a uint16. Toavert any risk of bit overflow, we add an extra sanity check for this inthat function. We cannot see that happen with the current code, butfuture designers being unaware of this risk, may introduce it byallowing delivery of very large (> 64k) sk buffers from the bearerlayer. This potential problem was identified by Eric Dumazet.This fixes CVE-2022-0435
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix use-after-free for aborted TMF sas_taskCurrently a use-after-free may occur if a TMF sas_task is aborted before wehandle the IO completion in mpi_ssp_completion(). The abort occurs due totimeout.When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and thesas_task is freed in pm8001_exec_internal_tmf_task().However, if the I/O completion occurs later, the I/O completion stillthinks that the sas_task is available. Fix this by clearing the ccb->taskif the TMF times out - the I/O completion handler does nothing if thispointer is cleared.
Packages affected:
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_taskCurrently a use-after-free may occur if a sas_task is aborted by the upperlayer before we handle the I/O completion in mpi_ssp_completion() ormpi_sata_completion().In this case, the following are the two steps in handling those I/Ocompletions: - Call complete() to inform the upper layer handler of completion of the I/O. - Release driver resources associated with the sas_task in pm8001_ccb_task_free() call.When complete() is called, the upper layer may free the sas_task. As such,we should not touch the associated sas_task afterwards, but we do so in thepm8001_ccb_task_free() call.Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.
Packages affected:
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: f_fs: Fix use-after-free for epfileConsider a case where ffs_func_eps_disable is called fromffs_func_disable as part of composition switch and at thesame time ffs_epfile_release get called from userspace.ffs_epfile_release will free up the read buffer and callffs_data_closed which in turn destroys ffs->epfiles andmark it as NULL. While this was happening the driver hasalready initialized the local epfile in ffs_func_eps_disablewhich is now freed and waiting to acquire the spinlock. Oncespinlock is acquired the driver proceeds with the stale valueof epfile and tries to free the already freed read buffercausing use-after-free.Following is the illustration of the race: CPU1 CPU2 ffs_func_eps_disable epfiles (local copy) ffs_epfile_release ffs_data_closed if (last file closed) ffs_data_reset ffs_data_clear ffs_epfiles_destroyspin_lockdereference epfilesFix this races by taking epfiles local copy & assigning it underspinlock and if epfiles(local) is null then update it in ffs->epfilesthen finally destroy it.Extending the scope further from the race, protecting the ep relatedstructures, and concurrent accesses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_queue: fix possible use-after-freeEric Dumazet says: The sock_hold() side seems suspect, because there is no guarantee that sk_refcnt is not already 0.On failure, we cannot queue the packet and need to indicate anerror. The packet will be dropped by the caller.v2: split skb prefetch hunk into separate change
Packages affected:
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memcg: fix possible use-after-free in memcg_write_event_control()memcg_write_event_control() accesses the dentry->d_name of the specifiedcontrol fd to route the write call. As a cgroup interface file can't berenamed, it's safe to access d_name as long as the specified file is aregular cgroup file. Also, as these cgroup interface files can't beremoved before the directory, it's safe to access the parent too.Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was acall to __file_cft() which verified that the specified file is a regularcgroupfs file before further accesses. The cftype pointer returned from__file_cft() was no longer necessary and the commit inadvertently droppedthe file type check with it allowing any file to slip through. With theinvarients broken, the d_name and parent accesses can now race againstrenames and removals of arbitrary files and cause use-after-free's.Fix the bug by resurrecting the file type check in __file_cft(). Now thatcgroupfs is implemented through kernfs, checking the file operations needsto go through a layer of indirection. Instead, let's check the superblockand dentry type.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcmu: Fix possible page UAFtcmu_try_get_data_page() looks up pages under cmdr_lock, but it does nottake refcount properly and just returns page pointer. Whentcmu_try_get_data_page() returns, the returned page may have been freed bytcmu_blocks_release().We need to get_page() under cmdr_lock to avoid concurrenttcmu_blocks_release().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix races among concurrent hw_params and hw_free callsCurrently we have neither proper check nor protection against theconcurrent calls of PCM hw_params and hw_free ioctls, which may resultin a UAF. Since the existing PCM stream lock can't be used forprotecting the whole ioctl operations, we need a new mutex to protectthose racy calls.This patch introduced a new mutex, runtime->buffer_mutex, and appliesit to both hw_params and hw_free ioctl code paths. Along with it, theboth functions are slightly modified (the mmap_count check is movedinto the state-check block) for code simplicity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: Set BIO_THROTTLED when bio has been throttled1.In current process, all bio will set the BIO_THROTTLED flagafter __blk_throtl_bio().2.If bio needs to be throttled, it will start the timer andstop submit bio directly. Bio will submit inblk_throtl_dispatch_work_fn() when the timer expires.But inthe current process, if bio is throttled. The BIO_THROTTLEDwill be set to bio after timer start. If the bio has beencompleted, it may cause use-after-free blow.BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70Read of size 2 at addr ffff88801b8902d4 by task fio/26380 dump_stack+0x9b/0xce print_address_description.constprop.6+0x3e/0x60 kasan_report.cold.9+0x22/0x3a blk_throtl_bio+0x12f0/0x2c70 submit_bio_checks+0x701/0x1550 submit_bio_noacct+0x83/0xc80 submit_bio+0xa7/0x330 mpage_readahead+0x380/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Allocated by task 26380: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.2+0xc1/0xd0 kmem_cache_alloc+0x146/0x440 mempool_alloc+0x125/0x2f0 bio_alloc_bioset+0x353/0x590 mpage_alloc+0x3b/0x240 do_mpage_readpage+0xddf/0x1ef0 mpage_readahead+0x264/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Freed by task 0: kasan_save_stack+0x19/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x1b/0x30 __kasan_slab_free+0x111/0x160 kmem_cache_free+0x94/0x460 mempool_free+0xd6/0x320 bio_free+0xe0/0x130 bio_put+0xab/0xe0 bio_endio+0x3a6/0x5d0 blk_update_request+0x590/0x1370 scsi_end_request+0x7d/0x400 scsi_io_completion+0x1aa/0xe50 scsi_softirq_done+0x11b/0x240 blk_mq_complete_request+0xd4/0x120 scsi_mq_done+0xf0/0x200 virtscsi_vq_done+0xbc/0x150 vring_interrupt+0x179/0x390 __handle_irq_event_percpu+0xf7/0x490 handle_irq_event_percpu+0x7b/0x160 handle_irq_event+0xcc/0x170 handle_edge_irq+0x215/0xb20 common_interrupt+0x60/0x120 asm_common_interrupt+0x1e/0x40Fix this by move BIO_THROTTLED set into the queue_lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Cancel pending work at closing a MIDI substreamAt closing a USB MIDI output substream, there might be still a pendingwork, which would eventually access the rawmidi runtime object that isbeing released. For fixing the race, make sure to cancel the pendingwork at closing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: zfcp: Fix double free of FSF request when qdio send failsWe used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cachethe FSF request ID when sending a new FSF request. This is used in case thesending fails and we need to remove the request from our internal hashtable again (so we don't keep an invalid reference and use it when we freethe request again).In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32bit wide), but the rest of the zfcp code (and the firmware specification)handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390xELF ABI]). For one this has the obvious problem that when the ID growspast 32 bit (this can happen reasonably fast) it is truncated to 32 bitwhen storing it in the cache variable and so doesn't match the original IDanymore. The second less obvious problem is that even when the original IDhas not yet grown past 32 bit, as soon as the 32nd bit is set in theoriginal ID (0x80000000 = 2'147'483'648) we will have a mismatch when wecast it back to 'unsigned long'. As the cached variable is of a signedtype, the compiler will choose a sign-extending instruction to load the 32bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So oncewe pass the cached variable into 'zfcp_reqlist_find_rm()' to remove therequest again all the leading zeros will be flipped to ones to extend thesign and won't match the original ID anymore (this has been observed inpractice).If we can't successfully remove the request from the hash table again after'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notifythe adapter about new work because the adapter is already gone duringe.g. a ChpID toggle) we will end up with a double free. We unconditionallyfree the request in the calling function when 'zfcp_fsf_req_send()' fails,but because the request is still in the hash table we end up with a stalememory reference, and once the zfcp adapter is either reset during recoveryor shutdown we end up freeing the same memory twice.The resulting stack traces vary depending on the kernel and have no directcorrelation to the place where the bug occurs. Here are three examples thathave been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: Fix use-after-free Read in usb_udc_uevent()The syzbot fuzzer found a race between uevent callbacks and gadgetdriver unregistration that can cause a use-after-free bug:---------------------------------------------------------------BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130drivers/usb/gadget/udc/core.c:1732Read of size 8 at addr ffff888078ce2050 by task udevd/2968CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google06/29/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424---------------------------------------------------------------The bug occurs because usb_udc_uevent() dereferences udc->driver butdoes so without acquiring the udc_lock mutex, which protects thisfield. If the gadget driver is unbound from the udc concurrently withuevent processing, the driver structure may be accessed after it hasbeen deallocated.To prevent the race, we make sure that the routine holds the mutexaround the racing accesses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Ensure scpi_info is not assigned if the probe failsWhen scpi probe fails, at any point, we need to ensure that the scpi_infois not set and will remain NULL until the probe succeeds. If it is nottaken care, then it could result use-after-free as the value is exportedvia get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()but freed when the probe fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Protect against send buffer overflow in NFSv2 READDIRRestore the previous limit on the @count argument to prevent abuffer overflow attack.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Do not free q_vector unless new one was allocatedAvoid potential use-after-free condition under memory pressure. If thekzalloc() fails, q_vector will be freed but left in the originaladapter->q_vector[v_idx] array position.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()This patch fixes a stack-out-of-bounds read in brcmfmac that occurswhen 'buf' that is not null-terminated is passed as an argument ofstrsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmwareversion string by memcpy() in brcmf_fil_iovar_data_get().The patch ensures buf is null-terminated.Found by a modified version of syzkaller.[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available[ 47.601565][ T1897] ==================================================================[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0[ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897[ 47.604336][ T1897][ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event[ 47.607453][ T1897] Call Trace:[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0[ 47.610882][ T1897] strsep+0x1b2/0x1f0[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0[ 47.616288][ T1897] brcmf_attach+0x246/0xd40[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0[ 47.617280][ T1897] ? kmemdup+0x43/0x50[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250[ 47.619950][ T1897] really_probe+0x205/0xb70[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130[ 47.622209][ T1897] driver_probe_device+0x4e/0x150[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160[ 47.625437][ T1897] __device_attach+0x23f/0x3a0[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0[ 47.627057][ T1897] bus_probe_device+0x1da/0x290[ 47.627557][ T1897] device_add+0xb7b/0x1eb0[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0[ 47.630385][ T1897] usb_probe_device+0xbb/0x250[ 47.630927][ T1897] ? usb_suspend+0x590/0x590[ 47.631397][ T1897] really_probe+0x205/0xb70[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0[ 47.633002][ ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:chardev: fix error handling in cdev_device_add()While doing fault injection test, I got the following report:------------[ cut here ]------------kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called.WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:kobject_put+0x23d/0x4e0Call Trace: cdev_device_add+0x15e/0x1b0 __iio_device_register+0x13b4/0x1af0 [industrialio] __devm_iio_device_register+0x22/0x90 [industrialio] max517_probe+0x3d8/0x6b4 [max517] i2c_device_probe+0xa81/0xc00When device_add() is injected fault and returns error, if dev->devt is not set,cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devtin error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: idle: Check acpi_fetch_acpi_dev() return valueThe return value of acpi_fetch_acpi_dev() could be NULL, which wouldcause a NULL pointer dereference to occur in acpi_device_hid().[ rjw: Subject and changelog edits, added empty line after if () ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: fix UAF/GPF bug in nilfs_mdt_destroyIn alloc_inode, inode_init_always() could return -ENOMEM ifsecurity_inode_alloc() fails, which causes inode->i_privateuninitialized. Then nilfs_is_metadata_file_inode() returnstrue and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),which frees the uninitialized inode->i_privateand leads to crashes(e.g., UAF/GPF).Fix this by moving security_inode_alloc just prior tothis_cpu_inc(nr_inodes)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix a crash in mempool_freeThere's a crash in mempool_free when running the lvm testshell/lvchange-rebuild-raid.sh.The reason for the crash is this:* super_written calls atomic_dec_and_test(&mddev->pending_writes) and wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev) and bio_put(bio).* so, the process that waited on sb_wait and that is woken up is racing with bio_put(bio).* if the process wins the race, it calls bioset_exit before bio_put(bio) is executed.* bio_put(bio) attempts to free a bio into a destroyed bio set - causing a crash in mempool_free.We fix this bug by moving bio_put before atomic_dec_and_test.We also move rdev_dec_pending before atomic_dec_and_test as suggested byNeil Brown.The function md_end_flush has a similar bug - we must call bio_put beforewe decrement the number of in-progress bios. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 11557f0067 P4D 11557f0067 PUD 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: kdelayd flush_expired_bios [dm_delay] RIP: 0010:mempool_free+0x47/0x80 Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00 RSP: 0018:ffff88910036bda8 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8 RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900 R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000 R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05 FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0 Call Trace: clone_endio+0xf4/0x1c0 [dm_mod] clone_endio+0xf4/0x1c0 [dm_mod] __submit_bio+0x76/0x120 submit_bio_noacct_nocheck+0xb6/0x2a0 flush_expired_bios+0x28/0x2f [dm_delay] process_one_work+0x1b4/0x300 worker_thread+0x45/0x3e0 ? rescuer_thread+0x380/0x380 kthread+0xc2/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [last unloaded: brd] CR2: 0000000000000000 ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix user-after-freeThis uses l2cap_chan_hold_unless_zero() after calling__l2cap_get_chan_blah() to prevent the following trace:Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref*kref)Bluetooth: chan 0000000023c4974dBluetooth: parent 00000000ae861c08==================================================================BUG: KASAN: use-after-free in __mutex_waiter_is_firstkernel/locking/mutex.c:191 [inline]BUG: KASAN: use-after-free in __mutex_lock_commonkernel/locking/mutex.c:671 [inline]BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400kernel/locking/mutex.c:729Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failureOn error situation `clp->cl_cb_conn.cb_xprt` should not be givena reference to the xprt otherwise both client cleanup and theerror handling path of the caller call to put it. Better todelay handing over the reference to a later branch.[ 72.530665] refcount_t: underflow; use-after-free.[ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120[ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc][ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1[ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014[ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd][ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120[ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48[ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286[ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000[ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0[ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff[ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180[ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0[ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000[ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0[ 72.554874] Call Trace:[ 72.555278] [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc][ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd][ 72.557087] ? update_load_avg+0x82/0x610[ 72.557652] ? cpuacct_charge+0x60/0x70[ 72.558212] ? dequeue_entity+0xdb/0x3e0[ 72.558765] ? queued_spin_unlock+0x9/0x20[ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd][ 72.560031] process_one_work+0x1df/0x390[ 72.560600] worker_thread+0x37/0x3b0[ 72.561644] ? process_one_work+0x390/0x390[ 72.562247] kthread+0x12f/0x150[ 72.562710] ? set_kthread_struct+0x50/0x50[ 72.563309] ret_from_fork+0x22/0x30[ 72.563818] [ 72.564189] ---[ end trace 031117b1c72ec616 ]---[ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018).[ 72.567647] ------------[ cut here ]------------
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);may be schedule, and then complete before the line> ndev->stats.tx_bytes += skb->len;[ 46.912801] ==================================================================[ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac][ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328[ 46.935991][ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1[ 46.947255] Hardware name: [REDACTED][ 46.954568] Call trace:[ 46.957037] dump_backtrace+0x0/0x2b8[ 46.960719] show_stack+0x24/0x30[ 46.964052] dump_stack+0x128/0x194[ 46.967557] print_address_description.isra.0+0x64/0x380[ 46.972877] __kasan_report+0x1d4/0x240[ 46.976723] kasan_report+0xc/0x18[ 46.980138] __asan_report_load4_noabort+0x18/0x20[ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac][ 46.990613] dev_hard_start_xmit+0x1bc/0xda0[ 46.994894] sch_direct_xmit+0x198/0xd08[ 46.998827] __qdisc_run+0x37c/0x1dc0[ 47.002500] __dev_queue_xmit+0x1528/0x21f8[ 47.006692] dev_queue_xmit+0x24/0x30[ 47.010366] neigh_resolve_output+0x37c/0x678[ 47.014734] ip_finish_output2+0x598/0x2458[ 47.018927] __ip_finish_output+0x300/0x730[ 47.023118] ip_output+0x2e0/0x430[ 47.026530] ip_local_out+0x90/0x140[ 47.030117] igmpv3_sendpack+0x14c/0x228[ 47.034049] igmpv3_send_cr+0x384/0x6b8[ 47.037895] igmp_ifc_timer_expire+0x4c/0x118[ 47.042262] call_timer_fn+0x1cc/0xbe8[ 47.046021] __run_timers+0x4d8/0xb28[ 47.049693] run_timer_softirq+0x24/0x40[ 47.053626] __do_softirq+0x2c0/0x117c[ 47.057387] irq_exit+0x2dc/0x388[ 47.060715] __handle_domain_irq+0xb4/0x158[ 47.064908] gic_handle_irq+0x58/0xb0[ 47.068581] el0_irq_naked+0x50/0x5c[ 47.072162][ 47.073665] Allocated by task 328:[ 47.077083] save_stack+0x24/0xb0[ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0[ 47.084776] kasan_slab_alloc+0x14/0x20[ 47.088622] kmem_cache_alloc+0x15c/0x468[ 47.092643] __alloc_skb+0xa4/0x498[ 47.096142] igmpv3_newpack+0x158/0xd78[ 47.099987] add_grhead+0x210/0x288[ 47.103485] add_grec+0x6b0/0xb70[ 47.106811] igmpv3_send_cr+0x2e0/0x6b8[ 47.110657] igmp_ifc_timer_expire+0x4c/0x118[ 47.115027] call_timer_fn+0x1cc/0xbe8[ 47.118785] __run_timers+0x4d8/0xb28[ 47.122457] run_timer_softirq+0x24/0x40[ 47.126389] __do_softirq+0x2c0/0x117c[ 47.130142][ 47.131643] Freed by task 180:[ 47.134712] save_stack+0x24/0xb0[ 47.138041] __kasan_slab_free+0x108/0x180[ 47.142146] kasan_slab_free+0x10/0x18[ 47.145904] slab_free_freelist_hook+0xa4/0x1b0[ 47.150444] kmem_cache_free+0x8c/0x528[ 47.154292] kfree_skbmem+0x94/0x108[ 47.157880] consume_skb+0x10c/0x5a8[ 47.161466] __dev_kfree_skb_any+0x88/0xa0[ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil][ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac][ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac][ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac][ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac][ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac][ 47.197859] process_one_work+0x7fc/0x1a80[ 47.201965] worker_thread+0x31c/0xc40[ 47.205726] kthread+0x2d8/0x370[ 47.208967] ret_from_fork+0x10/0x18[ 47.212546][ 47.214051] The buggy address belongs to the object at ffffff803f588280[ 47.214051] which belongs to the cache skbuff_head_cache of size 208[ 47.227086] The buggy address is located 104 bytes inside of[ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350)[ 47.238814] The buggy address belongs to the page:[ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memoryFixes the below NULL pointer dereference: [...] [ 14.471200] Call Trace: [ 14.471562] [ 14.471882] lock_acquire+0x245/0x2e0 [ 14.472416] ? remove_wait_queue+0x12/0x50 [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50 [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50 [ 14.474318] ? remove_wait_queue+0x12/0x50 [ 14.474907] remove_wait_queue+0x12/0x50 [ 14.475480] sk_stream_wait_memory+0x20d/0x340 [ 14.476127] ? do_wait_intr_irq+0x80/0x80 [ 14.476704] do_tcp_sendpages+0x287/0x600 [ 14.477283] tcp_bpf_push+0xab/0x260 [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500 [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0 [ 14.479096] tcp_bpf_send_verdict+0x105/0x470 [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0 [ 14.480311] sock_sendmsg+0x2d/0x40 [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0 [ 14.481390] ? copy_msghdr_from_user+0x62/0x80 [ 14.482048] ___sys_sendmsg+0x78/0xb0 [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150 [ 14.483215] ? __do_fault+0x2a/0x1a0 [ 14.483738] ? do_fault+0x15e/0x5d0 [ 14.484246] ? __handle_mm_fault+0x56b/0x1040 [ 14.484874] ? lock_is_held_type+0xdf/0x130 [ 14.485474] ? find_held_lock+0x2d/0x90 [ 14.486046] ? __sys_sendmsg+0x41/0x70 [ 14.486587] __sys_sendmsg+0x41/0x70 [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350 [ 14.487822] do_syscall_64+0x34/0x80 [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd [...]The test scenario has the following flow:thread1 thread2----------- --------------- tcp_bpf_sendmsg tcp_bpf_send_verdict tcp_bpf_sendmsg_redir sock_close tcp_bpf_push_locked __sock_release tcp_bpf_push //inet_release do_tcp_sendpages sock->ops->release sk_stream_wait_memory // tcp_close sk_wait_event sk->sk_prot->close release_sock(__sk); *** lock_sock(sk); __tcp_close sock_orphan(sk) sk->sk_wq = NULL release_sock **** lock_sock(__sk); remove_wait_queue(sk_sleep(sk), &wait); sk_sleep(sk) //NULL pointer dereference &rcu_dereference_raw(sk->sk_wq)->waitWhile waiting for memory in thread1, the socket is released with its waitqueue because thread2 has closed it. This caused by tcp_bpf_send_verdictdidn't increase the f_count of psock->sk_redir->sk_socket->file in thread1.We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memorybefore accessing the wait queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernfs: fix use-after-free in __kernfs_removeSyzkaller managed to trigger concurrent calls tokernfs_remove_by_name_ns() for the same file resulting ina KASAN detected use-after-free. The race occurs when the rootnode is freed during kernfs_drain().To prevent this acquire an additional reference for the rootof the tree that is removed before calling __kernfs_remove().Found by syzkaller with the following reproducer (slab_nomerge isrequired):syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0)close(r0)pipe2(&(0x7f0000000140)={0xffffffffffffffff, 0xffffffffffffffff}, 0x800)mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}})Sample report:==================================================================BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline]BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [inline] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f725f983aedCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aedRDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000 Allocated by task 855: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:7---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free in ext4_orphan_cleanupI caught a issue as follows:================================================================== BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0 Read of size 8 at addr ffff88814b13f378 by task mount/710 CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370 Call Trace: dump_stack_lvl+0x73/0x9f print_report+0x25d/0x759 kasan_report+0xc0/0x120 __asan_load8+0x99/0x140 __list_add_valid+0x28/0x1a0 ext4_orphan_cleanup+0x564/0x9d0 [ext4] __ext4_fill_super+0x48e2/0x5300 [ext4] ext4_fill_super+0x19f/0x3a0 [ext4] get_tree_bdev+0x27b/0x450 ext4_get_tree+0x19/0x30 [ext4] vfs_get_tree+0x49/0x150 path_mount+0xaae/0x1350 do_mount+0xe2/0x110 __x64_sys_mount+0xf0/0x190 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...]==================================================================Above issue may happen as follows:-------------------------------------ext4_fill_super ext4_orphan_cleanup --- loop1: assume last_orphan is 12 --- list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan) ext4_truncate --> return 0 ext4_inode_attach_jinode --> return -ENOMEM iput(inode) --> free inode<12> --- loop2: last_orphan is still 12 --- list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan); // use inode<12> and trigger UAFTo solve this issue, we need to propagate the return value ofext4_inode_attach_jinode() appropriately.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mrp: introduce active flags to prevent UAF when applicant uninitThe caller of del_timer_sync must prevent restarting of the timer, Ifwe have no this synchronization, there is a small probability that thecancellation will not be successful.And syzbot report the fellowing crash:==================================================================BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605Write at addr f9ff000024df6058 by task syz-fuzzer/2256Pointer tag: [f9], memory tag: [fe]CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-ge01d50cbd6ee #0Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519To fix it, we can introduce a new active flags to make sure the timer willnot restart.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - fix DMA transfer directionWhen CONFIG_DMA_API_DEBUG is selected, while running the crypto selftest on the QAT crypto algorithms, the function add_dma_entry() reportsa warning similar to the one below, saying that overlapping mappingsare not supported. This occurs in tests where the input and the outputscatter list point to the same buffers (i.e. two different scatter listswhich point to the same chunks of memory).The logic that implements the mapping uses the flag DMA_BIDIRECTIONALfor both the input and the output scatter lists which leads tooverlapped write mappings. These are not supported by the DMA layer.Fix by specifying the correct DMA transfer directions when mappingbuffers. For in-place operations where the input scatter listmatches the output scatter list, buffers are mapped once withDMA_BIDIRECTIONAL, otherwise input buffers are mapped using the flagDMA_TO_DEVICE and output buffers are mapped with DMA_FROM_DEVICE.Overlapping a read mapping with a write mapping is a valid case indma-coherent devices like QAT.The function that frees and unmaps the buffers, qat_alg_free_bufl()has been changed accordingly to the changes to the mapping function. DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270 ... Call Trace: dma_map_page_attrs+0x82/0x2d0 ? preempt_count_add+0x6a/0xa0 qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat] crypto_aead_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 ? scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 ? test_aead_vec+0xdf/0x120 test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 ? crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30 cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sudo < 1.8.27-4.48.2 (version in image is 1.8.27-4.38.1).
-
Description: bt_sock_recvmsg in net/bluetooth/af_bluetooth.c in the Linux kernel through 6.6.8 has a use-after-free because of a bt_sock_ioctl race condition.
Packages affected:
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.Getting a reference on the socket found in a lookup whileholding a lock should happen before releasing the lock.nfc_llcp_sock_get_sn() has a similar problem.Finally nfc_llcp_recv_snl() needs to make sure the socketfound by nfc_llcp_sock_from_sn() does not disappear.
Packages affected:
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ravb: Fix use-after-free issue in ravb_tx_timeout_work()The ravb_stop() should call cancel_work_sync(). Otherwise,ravb_tx_timeout_work() is possible to use the freed priv afterravb_remove() was called like below:CPU0 CPU1 ravb_tx_timeout()ravb_remove()unregister_netdev()free_netdev(ndev)// free priv ravb_tx_timeout_work() // use privunregister_netdev() will call .ndo_stop() so that ravb_stop() iscalled. And, after phy_stop() is called, netif_carrier_off()is also called. So that .ndo_tx_timeout() will not be calledafter phy_stop().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race conditionIn btsdio_probe, the data->work is bound with btsdio_work. It will bestarted in btsdio_send_frame.If the btsdio_remove runs with a unfinished work, there may be a racecondition that hdev is freed but used in btsdio_work. Fix it bycanceling the work before do cleanup in btsdio_remove.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cacheinfo: Fix shared_cpu_map to handle shared caches at different levelsThe cacheinfo sets up the shared_cpu_map by checking whether the cacheswith the same index are shared between CPUs. However, this will triggerslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.Another problem is the mismatched shared_cpu_map when the shared cache doesnot have the same index between CPUs.CPU0 I D L3index 0 1 2 x ^ ^ ^ ^index 0 1 2 3CPU1 I D L2 L3This patch checks each cache is shared with all caches on other CPUs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211_hwsim: drop short framesWhile technically some control frames like ACK are shorter andend after Address 1, such frames shouldn't be forwarded throughwmediumd or similar userspace, so require the full 3-addressheader to avoid accessing invalid memory if shorter frames arepassed in.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Add AML_NO_OPERAND_RESOLVE flag to TimerACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.=============================================================UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'CPU: 37 PID: 1678 Comm: cat Not tainted6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64kHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()Fix a stack-out-of-bounds write that occurs in a WMI response callbackfunction that is called after a timeout occurs in ath9k_wmi_cmd().The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer thatcould no longer be valid when a timeout occurs. Set wmi->last_seq_id to0 when a timeout occurred.Found by a modified version of syzkaller.BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rxWrite of size 4Call Trace: memcpy ath9k_wmi_ctrl_rx ath9k_htc_rx_msg ath9k_hif_usb_reg_in_cb __usb_hcd_giveback_urb usb_hcd_giveback_urb dummy_timer call_timer_fn run_timer_softirq __do_softirq irq_exit_rcu sysvec_apic_timer_interrupt
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in tcp_write_timer_handler().With Eric's ref tracker, syzbot finally found a repro foruse-after-free in tcp_write_timer_handler() by kernel TCPsockets. [0]If SMC creates a kernel socket in __smc_create(), the kernelsocket is supposed to be freed in smc_clcsock_release() bycalling sock_release() when we close() the parent SMC socket.However, at the end of smc_clcsock_release(), the kernelsocket's sk_state might not be TCP_CLOSE. This means thatwe have not called inet_csk_destroy_sock() in __tcp_close()and have not stopped the TCP timers.The kernel socket's TCP timers can be fired later, so weneed to hold a refcnt for net as we do for MPTCP subflowsin mptcp_subflow_create_socket().[0]:leaked reference. sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108) inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244) __sock_create (net/socket.c:1546) smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284) __sock_create (net/socket.c:1546) __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661) __x64_sys_socket (net/socket.c:1672) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)==================================================================BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) kasan_report (mm/kasan/report.c:538) tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022) run_timer_softirq (kernel/time/timer.c:2037) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572) __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650) irq_exit_rcu (kernel/softirq.c:664) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()The ucmd->log_sq_bb_count variable is controlled by the user so thisshift can wrap. Fix it by using check_shl_overflow() in the same waythat it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefinedbehavior in hns_roce_set_user_sq_size()").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A heap out-of-bounds write vulnerability in the Linux kernel's Performance Events system component can be exploited to achieve local privilege escalation.A perf_event's read_size can overflow, leading to an heap out-of-bounds increment or write in perf_read_group().We recommend upgrading past commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b.
Packages affected:
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation.A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread.We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1.
Packages affected:
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: fix race between tx work scheduling and socket closeSimilarly to previous commit, the submitting thread (recvmsg/sendmsg)may exit as soon as the async crypto handler calls complete().Reorder scheduling the work before calling complete().This seems more logical in the first place, as it'sthe inverse order of what the submitting thread will do.
Packages affected:
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix garbage collector racing against connect()Garbage collector does not take into account the risk of embryo gettingenqueued during the garbage collection. If such embryo has a peer thatcarries SCM_RIGHTS, two consecutive passes of scan_children() may see adifferent set of children. Leading to an incorrectly elevated inflightcount, and then a dangling pointer within the gc_inflight_list.sockets are AF_UNIX/SOCK_STREAMS is an unconnected socketL is a listening in-flight socket bound to addr, not in fdtableV's fd will be passed via sendmsg(), gets inflight count bumpedconnect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()---------------- ------------------------- -----------NS = unix_create1()skb1 = sock_wmalloc(NS)L = unix_find_other(addr)unix_state_lock(L)unix_peer(S) = NS // V count=1 inflight=0 NS = unix_peer(S) skb2 = sock_alloc() skb_queue_tail(NS, skb2[V]) // V became in-flight // V count=2 inflight=1 close(V) // V count=1 inflight=1 // GC candidate condition met for u in gc_inflight_list: if (total_refs == inflight_refs) add u to gc_candidates // gc_candidates={L, V} for u in gc_candidates: scan_children(u, dec_inflight) // embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged__skb_queue_tail(L, skb1)unix_state_unlock(L) for u in gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail) // V count=1 inflight=2 (!)If there is a GC-candidate listening socket, lock/unlock its state. Thismakes GC wait until the end of any ongoing connect() to that socket. Afterflipping the lock, a possibly SCM-laden embryo is already enqueued. And ifthere is another embryo coming, it can not possibly carry SCM_RIGHTS. Atthis point, unix_inflight() can not happen because unix_gc_lock is alreadytaken. Inflight graph remains unaffected.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: make sure that WRITTEN is set on all metadata blocksWe previously would call btrfs_check_leaf() if we had the checkintegrity code enabled, which meant that we could only run the extendedleaf checks if we had WRITTEN set on the header flags.This leaves a gap in our checking, because we could end up withcorruption on disk where WRITTEN isn't set on the leaf, and then theextended leaf checks don't get run which we rely on to validate all ofthe item pointers to make sure we don't access memory outside of theextent buffer.However, since 732fab95abe2 ("btrfs: check-integrity: removeCONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer callbtrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we onlyever call it on blocks that are being written out, and thus have WRITTENset, or that are being read in, which should have WRITTEN set.Add checks to make sure we have WRITTEN set appropriately, and then makesure __btrfs_check_leaf() always does the item checking. This willprotect us from file systems that have been corrupted and no longer haveWRITTEN set on some of the blocks.This was hit on a crafted image tweaking the WRITTEN bit and reported byKASAN as out-of-bound access in the eb accessors. The example is a diritem at the end of an eb. [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2 [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8 [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Call Trace: [2.621] [2.621] ? show_regs+0x74/0x80 [2.621] ? die_addr+0x46/0xc0 [2.621] ? exc_general_protection+0x161/0x2a0 [2.621] ? asm_exc_general_protection+0x26/0x30 [2.621] ? btrfs_get_16+0x33a/0x6d0 [2.621] ? btrfs_get_16+0x34b/0x6d0 [2.621] ? btrfs_get_16+0x33a/0x6d0 [2.621] ? __pfx_btrfs_get_16+0x10/0x10 [2.621] ? __pfx_mutex_unlock+0x10/0x10 [2.621] btrfs_match_dir_item_name+0x101/0x1a0 [2.621] btrfs_lookup_dir_item+0x1f3/0x280 [2.621] ? __pfx_btrfs_lookup_dir_item+0x10/0x10 [2.621] btrfs_get_tree+0xd25/0x1910[ copy more details from report ]
Packages affected:
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/client: Fully protect modes[] with dev->mode_config.mutexThe modes[] array contains pointers to modes on the connectors'mode lists, which are protected by dev->mode_config.mutex.Thus we need to extend modes[] the same protection or by thetime we use it the elements may already be pointing tofreed/reused memory.
Packages affected:
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Fix race between aio_cancel() and AIO request completeFFS based applications can utilize the aio_cancel() callback to dequeuepending USB requests submitted to the UDC. There is a scenario where theFFS application issues an AIO cancel call, while the UDC is handling asoft disconnect. For a DWC3 based implementation, the callstack lookslike the following: DWC3 Gadget FFS Applicationdwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue()There is currently no locking implemented between the AIO completionhandler and AIO cancel, so the issue occurs if the completion routine isrunning in parallel to an AIO cancel call coming from the FFS application.As the completion call frees the USB request (io_data->req) the FFSapplication is also referencing it for the usb_ep_dequeue() call. This canlead to accessing a stale/hanging pointer.commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().However, in order to properly implement locking to mitigate this issue, thespinlock can't be added to ffs_epfile_async_io_complete(), asusb_ep_dequeue() (if successfully dequeuing a USB request) will call thefunction driver's completion handler in the same context. Hence, leadinginto a deadlock.Fix this issue by moving the usb_ep_free_request() back toffs_user_copy_worker(), and ensuring that it explicitly sets io_data->reqto NULL after freeing it within the ffs->eps_lock. This resolves the racecondition above, as the ffs_aio_cancel() routine will not continueattempting to dequeue a request that has already been freed, or theffs_user_copy_work() not freeing the USB request until the AIO cancel isdone referencing it.This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bluetooth/l2cap: sync sock recv cb and releaseThe problem occurs between the system call to close the sock and hci_rx_work,where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cbIf hci_rx_work processes the data that needs to be received before the sock isclosed, then everything is normal; Otherwise, the work thread may access thereleased sock when receiving data.Add a chan mutex in the rx callback of the sock to achieve synchronization betweenthe sock release and recv cb.Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.
Packages affected:
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-core: Fix double free on errorIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jumpto the err_out label, which will call devres_release_group().devres_release_group() will trigger a call to ata_host_release().ata_host_release() calls kfree(host), so executing the kfree(host) inata_host_alloc() will lead to a double free:kernel BUG at mm/slub.c:553!Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:kfree+0x2cf/0x2f0Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 daRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]Ensure that we will not call kfree(host) twice, by performing the kfree()only if the devres_open_group() call failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix race between delayed_work() and ceph_monc_stop()The way the delayed work is handled in ceph_monc_stop() is prone toraces with mon_fault() and possibly also finish_hunting(). Both ofthese can requeue the delayed work which wouldn't be canceled by any ofthe following code in case that happens after cancel_delayed_work_sync()runs -- __close_session() doesn't mess with the delayed work in orderto avoid interfering with the hunting interval logic. This part wasmissed in commit b5d91704f53e ("libceph: behave in mon_fault() ifcur_mon < 0") and use-after-free can still ensue on monc and objectsthat hang off of it, with monc->auth and monc->monmap beingparticularly susceptible to quickly being reused.To fix this:- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)- call cancel_delayed_work_sync() after the session is closed
Packages affected:
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/iucv: fix use after free in iucv_sock_close()iucv_sever_path() is called from process context and from bh context.iucv->path is used as indicator whether somebody else is taking care ofsevering the path (or it is already removed / never existed).This needs to be done with atomic compare and swap, otherwise there is asmall window where iucv_sock_close() will try to work with a path that hasalready been severed and freed by iucv_callback_connrej() called byiucv_tasklet_fn().Example:[452744.123844] Call Trace:[452744.123845] ([<0000001e87f03880>] 0x1e87f03880)[452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138[452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv][452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv][452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv][452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8[452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48[452744.124820] [<00000000d5421642>] __fput+0xba/0x268[452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0[452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90[452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8[452744.125319] Last Breaking-Event-Address:[452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138[452744.125324][452744.125325] Kernel panic - not syncing: Fatal exception in interruptNote that bh_lock_sock() is not serializing the tasklet context againstprocess context, because the check for sock_owned_by_user() andcorresponding handling is missing.Ideas for a future clean-up patch:A) Correct usage of bh_lock_sock() in tasklet context, as described inRe-enqueue, if needed. This may require adding return values to thetasklet functions and thus changes to all users of iucv.B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exec: Fix ToCToU between perm check and set-uid/gid usageWhen opening a file for exec via do_filp_open(), permission checking isdone against the file's metadata at that moment, and on success, a filepointer is passed back. Much later in the execve() code path, the filemetadata (specifically mode, uid, and gid) is used to determine if/howto set the uid and gid. However, those values may have changed since thepermissions check, meaning the execution may gain unintended privileges.For example, if a file could change permissions from executable and notset-id:---------x 1 root root 16048 Aug 7 13:16 targetto set-id and non-executable:---S------ 1 root root 16048 Aug 7 13:16 targetit is possible to gain root privileges when execution should have beendisallowed.While this race condition is rare in real-world scenarios, it has beenobserved (and proven exploitable) when package managers are updatingthe setuid bits of installed programs. Such files start with beingworld-executable but then are adjusted to be group-exec with a set-uidbit. For example, "chmod o-x,u+s target" makes "target" executable onlyby uid "root" and gid "cdrom", while also becoming setuid-root:-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 targetbecomes:-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 targetBut racing the chmod means users without group "cdrom" membership canget the permission to execute "target" just before the chmod, and whenthe chmod finishes, the exec reaches brpm_fill_uid(), and performs thesetuid to root, violating the expressed authorization of "only cdromgroup members can setuid to root".Re-check that we still have execute permissions in case the metadatahas changed. It would be better to keep a copy from the perm-check time,but until we can do that refactoring, the least-bad option is to do afull inode_permission() call (under inode lock). It is understood thatthis is safe against dead-locks, but hardly optimal.
Packages affected:
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netem: fix return value if duplicate enqueue failsThere is a bug in netem_enqueue() introduced bycommit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")that can lead to a use-after-free.This commit made netem_enqueue() always return NET_XMIT_SUCCESSwhen a packet is duplicated, which can cause the parent qdisc's q.qlento be mistakenly incremented. When this happens qlen_notify() may beskipped on the parent during destruction, leaving a dangling pointerfor some classful qdiscs like DRR.There are two ways for the bug happen:- If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped.- If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped.In both cases NET_XMIT_SUCCESS is returned even though no packetsare enqueued at the netem qdisc.The fix is to defer the enqueue of the duplicate packet until afterthe original packet has been guaranteed to return NET_XMIT_SUCCESS.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: avoid leaving partial pfn mappings around in error caseAs Jann points out, PFN mappings are special, because unlike normalmemory mappings, there is no lifetime information associated with themapping - it is just a raw mapping of PFNs with no reference counting ofa 'struct page'.That's all very much intentional, but it does mean that it's easy tomess up the cleanup in case of errors. Yes, a failed mmap() will alwayseventually clean up any partial mappings, but without any explicitlifetime in the page table mapping itself, it's very easy to do theerror handling in the wrong order.In particular, it's easy to mistakenly free the physical backing storebefore the page tables are actually cleaned up and (temporarily) havestale dangling PTE entries.To make this situation less error-prone, just make sure that any partialpfn mapping is torn down early, before any other error handling.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block, bfq: fix possible UAF for bfqq->bic with merge chain1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | ^ | ^ | ^ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3process ref: 1 1 12) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | ^ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3process ref: 0 2 13) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> ^ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3process ref: 0 1 3In this case, IO from Process 1 will get bfqq2 from BIC1 first, and thenget bfqq3 through merge chain, and finially handle IO by bfqq3.Howerver, current code will think bfqq2 is owned by BIC1, like initialstate, and set bfqq2->bic to BIC1.bfq_insert_request-> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3Fix the problem by checking bfqq is from merge chain fist. And thismight fix a following problem reported by our syzkaller(unreproducible):==================================================================BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014Workqueue: kblockd blk_mq_requeue_workCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline]---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: wait for fixup workers before stopping cleaner kthread during umountDuring unmount, at close_ctree(), we have the following steps in this order:1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing);2) We stop the cleaner kthread - this results in freeing the respective struct task_struct;3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues.Syzbot reported a case where a fixup worker resulted in a crash when doinga delayed iput on its inode while attempting to wake up the cleaner atbtrfs_add_delayed_iput(), because the task_struct of the cleaner kthreadwas already freed. This can happen during unmount because we don't waitfor any fixup workers still running before we call kthread_stop() againstthe cleaner kthread, which stops and free all its resources.Fix this by waiting for any fixup workers at close_ctree() before we callkthread_stop() against the cleaner and run pending delayed iputs.The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/xen-netback: prevent UAF in xenvif_flush_hash()During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,kfree_rcu does not exist inside the rcu read critical section, so ifkfree_rcu is called when the rcu grace period ends during the iteration,UAF occurs when accessing head->next after the entry becomes free.Therefore, to solve this, you need to change it to list_for_each_entry_safe.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """The commit 83fccfc3940c ("inet: fix potential deadlock inreqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() notto call del_timer_sync() from reqsk_timer_handler(), but it introduced asmall race window.Before the timer is called, expire_timers() calls detach_timer(timer, true)to clear timer->entry.pprev and marks it as not pending.If reqsk_queue_unlink() checks timer_pending() just after expire_timers()calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer willcontinue running and send multiple SYN+ACKs until it expires.The reported UAF could happen if req->sk is close()d earlier than the timerexpiration, which is 63s by default.The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->skLet's not use timer_pending() by passing the caller context to__inet_csk_reqsk_queue_drop().Note that reqsk timer is pinned, so the issue does not happen in mostuse cases. [1][0]BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0Use-after-free read at 0x00000000a891fb3a (in kfence-#1):bpf_sk_storage_get_tracing+0x2e/0x1b0bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1ddabpf_trace_run2+0x4c/0xc0tcp_rtx_synack+0xf9/0x100reqsk_timer_handler+0xda/0x3d0run_timer_softirq+0x292/0x8a0irq_exit_rcu+0xf5/0x320sysvec_apic_timer_interrupt+0x6d/0x80asm_sysvec_apic_timer_interrupt+0x16/0x20intel_idle_irq+0x5a/0xa0cpuidle_enter_state+0x94/0x273cpu_startup_entry+0x15e/0x260start_secondary+0x8a/0x90secondary_startup_64_no_verify+0xfa/0xfbkfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6allocated by task 0 on cpu 9 at 260507.901592s:sk_prot_alloc+0x35/0x140sk_clone_lock+0x1f/0x3f0inet_csk_clone_lock+0x15/0x160tcp_create_openreq_child+0x1f/0x410tcp_v6_syn_recv_sock+0x1da/0x700tcp_check_req+0x1fb/0x510tcp_v6_rcv+0x98b/0x1420ipv6_list_rcv+0x2258/0x26e0napi_complete_done+0x5b1/0x2990mlx5e_napi_poll+0x2ae/0x8d0net_rx_action+0x13e/0x590irq_exit_rcu+0xf5/0x320common_interrupt+0x80/0x90asm_common_interrupt+0x22/0x40cpuidle_enter_state+0xfb/0x273cpu_startup_entry+0x15e/0x260start_secondary+0x8a/0x90secondary_startup_64_no_verify+0xfa/0xfbfreed by task 0 on cpu 9 at 260507.927527s:rcu_core_si+0x4ff/0xf10irq_exit_rcu+0xf5/0x320sysvec_apic_timer_interrupt+0x6d/0x80asm_sysvec_apic_timer_interrupt+0x16/0x20cpuidle_enter_state+0xfb/0x273cpu_startup_entry+0x15e/0x260start_secondary+0x8a/0x90secondary_startup_64_no_verify+0xfa/0xfb
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4.0: Fix a use-after-free problem in the asynchronous open()Yang Erkun reports that when two threads are opening files at the sametime, and are forced to abort before a reply is seen, then the call tonfs_release_seqid() in nfs4_opendata_free() can result in ause-after-free of the pointer to the defunct rpc task of the otherthread.The fix is to ensure that if the RPC call is aborted before the call tonfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()in nfs4_open_release() before the rpc_task is freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free of signing keyCustomers have reported use-after-free in @ses->auth_key.response withSMB2.1 + sign mounts which occurs due to following race:task A task Bcifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF*Fix this by ensuring that we have a valid @ses->auth_key.response bychecking whether @ses->ses_status is SES_GOOD or SES_EXITING with@ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAFin smb2_reconnect_server()"), we made sure to call ->logoff() onlywhen @ses was known to be good (e.g. valid ->auth_key.response), soit's safe to access signing key when @ses->ses_status == SES_EXITING.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.81.1 (version in image is 2.9.4-46.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix use after free on unloadSystem crash is observed with stack trace warning of use afterfree. There are 2 signals to tell dpc_thread to terminate (UNLOADINGflag and kthread_stop).On setting the UNLOADING flag when dpc_thread happens to run at the timeand sees the flag, this causes dpc_thread to exit and clean upitself. When kthread_stop is called for final cleanup, this causes useafter free.Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stopas the main signal to exit dpc_thread.[596663.812935] kernel BUG at mm/slub.c:294![596663.812950] invalid opcode: 0000 [#1] SMP PTI[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012[596663.812974] RIP: 0010:__slab_free+0x17d/0x360...[596663.813008] Call Trace:[596663.813022] ? __dentry_kill+0x121/0x170[596663.813030] ? _cond_resched+0x15/0x30[596663.813034] ? _cond_resched+0x15/0x30[596663.813039] ? wait_for_completion+0x35/0x190[596663.813048] ? try_to_wake_up+0x63/0x540[596663.813055] free_task+0x5a/0x60[596663.813061] kthread_stop+0xf3/0x100[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Fix slab-use-after-free read in sg_release()Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30kernel/locking/lockdep.c:5838__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) iscalled before releasing the open_rel_lock mutex. The kref_put() call maydecrement the reference count of sfp to zero, triggering its cleanupthrough sg_remove_sfp(). This cleanup includes scheduling deferred workvia sg_remove_sfp_usercontext(), which ultimately frees sfp.After kref_put(), sg_release() continues to unlock open_rel_lock and mayreference sfp or sdp. If sfp has already been freed, this results in aslab-use-after-free error.Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking theopen_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release().The fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures propersequencing of resource cleanup and mutex operations, eliminating therisk of use-after-free errors in sg_release().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix race between element replace and close()Element replace (with a socket different from the one stored) may racewith socket's close() link popping & unlinking. __sock_map_delete()unconditionally unrefs the (wrong) element:// set map[0] = s0map_update_elem(map, 0, s0)// drop fd of s0close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)Then close(map) enqueues bpf_map_free_deferred, which finally callssock_map_free(). This results in some refcount_t warnings along witha KASAN splat [1].Fix __sock_map_delete(), do not allow sock_map_unref() on elements thatmay have been replaced.[1]:BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014Workqueue: events_unbound bpf_map_free_deferredCall Trace: dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30The bu---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when COWing tree bock and tracing is enabledWhen a COWing a tree block, at btrfs_cow_block(), and we have thetracepoint trace_btrfs_cow_block() enabled and preemption is also enabled(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extentbuffer while inside the tracepoint code. This is because in some pathsthat call btrfs_cow_block(), such as btrfs_search_slot(), we are holdingthe last reference on the extent buffer @buf so btrfs_force_cow_block()drops the last reference on the @buf extent buffer when it callsfree_extent_buffer_stale(buf), which schedules the release of the extentbuffer with RCU. This means that if we are on a kernel with preemption,the current task may be preempted before calling trace_btrfs_cow_block()and the extent buffer already released by the time trace_btrfs_cow_block()is called, resulting in a use-after-free.Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() tobtrfs_force_cow_block() before the COWed extent buffer is freed.This also has a side effect of invoking the tracepoint in the tree defragcode, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() iscalled there, but this is fine and it was actually missing there.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: seq: oss: Fix races at processing SysEx messagesOSS sequencer handles the SysEx messages split in 6 bytes packets, andALSA sequencer OSS layer tries to combine those. It stores the datain the internal buffer and this access is racy as of now, which maylead to the out-of-bounds access.As a temporary band-aid fix, introduce a mutex for serializing theprocess of the SysEx message packets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3-setuptools < 40.6.2-4.24.1 (version in image is 40.6.2-4.21.1).
-
Description: Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sudo < 1.8.27-4.54.1 (version in image is 1.8.27-4.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: move the limit validationIt is not sufficient to directly validate the limit on the data thatthe user passes as it can be updated based on how the other parametersare changed.Move the check at the end of the configuration update process to alsocatch scenarios where the limit is indirectly updated, for examplewith the following configurations:tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1This fixes the following syzkaller reported crash:------------[ cut here ]------------UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6index 65535 is out of range for type 'struct sfq_head[128]'CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls thechild qdisc's peek() operation before incrementing sch->q.qlen andsch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this maytrigger an immediate dequeue and potential packet drop. In such cases,qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backloghave not yet been updated, leading to inconsistent queue accounting. Thiscan leave an empty HFSC class in the active list, causing furtherconsequences like use-after-free.This patch fixes the bug by moving the increment of sch->q.qlen andsch->qstats.backlog before the call to the child qdisc's peek() operation.This ensures that queue length and backlog are always accurate when packetdrops or dequeues are triggered during the peek.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: algif_hash - fix double free in hash_acceptIf accept(2) is called on socket type algif_hash withMSG_MORE flag set and crypto_ahash_import fails,sk2 is freed. However, it is also freed in af_alg_release,leading to slab-use-after-free error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch_hfsc: make hfsc_qlen_notify() idempotenthfsc_qlen_notify() is not idempotent either and not friendlyto its callers, like fq_codel_dequeue(). Let's make it idempotentto ease qdisc_tree_reduce_backlog() callers' life:1. update_vf() decreases cl->cl_nactive, so we can check whether it isnon-zero before calling it.2. eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atm: add lec_mutexsyzbot found its way in net/atm/lec.c, and found an error pathin lecd_attach() could leave a dangling pointer in dev_lec[].Add a mutex to protect dev_lecp[] uses from lecd_attach(),lec_vcc_attach() and lec_mcast_attach().Following patch will use this mutex for /proc/net/atm/lec.BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 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/0x7f Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 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/0x7fFreed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()If an exiting non-autoreaping task has already passed exit_notify() andcalls handle_posix_cpu_timers() from IRQ, it can be reaped by its parentor debugger right after unlock_task_sighand().If a concurrent posix_cpu_timer_del() runs at that moment, it won't beable to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/orlock_task_sighand() will fail.Add the tsk->exit_state check into run_posix_cpu_timers() to fix this.This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, becauseexit_task_work() is called before exit_notify(). But the check stillmakes sense, task_work_add(&tsk->posix_cputimers_work.work) will failanyway in this case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: ensure the received length does not exceed allocated sizeIn xdp_linearize_page, when reading the following buffers from the ring,we forget to check the received length with the true allocate size. Thiscan lead to an out-of-bound read. This commit adds that missing check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix race condition on qfq_aggregateA race condition can occur when 'agg' is modified in qfq_change_agg(called during qfq_enqueue) while other threads access itconcurrently. For example, qfq_dump_class may trigger a NULLdereference, and qfq_delete_class may cause a use-after-free.This patch addresses the issue by:1. Moved qfq_destroy_class into the critical section.2. Added sch_tree_lock protection to qfq_dump_class andqfq_dump_class_stats.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:do_change_type(): refuse to operate on unmounted/not ours mountsEnsure that propagation settings can only be changed for mounts locatedin the caller's mount namespace. This change aligns permission checkingwith the rest of mount(2).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix a race in packet_set_ring() and packet_notifier()When packet_set_ring() releases po->bind_lock, another thread canrun packet_notifier() and process an NETDEV_UP event.This race and the fix are both similar to that of commit 15fe076edea7("net/packet: fix a race in packet_bind() and packet_notifier()").There too the packet_notifier NETDEV_UP event managed to run while apo->bind_lock critical section had to be temporarily released. Andthe fix was similarly to temporarily set po->num to zero to keepthe socket unhooked until the lock is retaken.The po->bind_lock in packet_set_ring and packet_notifier precede theintroduction of git history.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Do not allow binding to VMADDR_PORT_ANYIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This cancause a use-after-free when a connection is made to the bound socket.The socket returned by accept() also has port VMADDR_PORT_ANY but is noton the list of unbound sockets. Binding it will result in an extrarefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keepthe binding until socket destruction).Modify the check in __vsock_bind_connectible() to also prevent bindingto VMADDR_PORT_ANY.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject TDLS operations when station is not associatedsyzbot triggered a WARN in ieee80211_tdls_oper() by sendingNL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,before association completed and without prior TDLS setup.This left internal state like sdata->u.mgd.tdls_peer uninitialized,leading to a WARN_ON() in code paths that assumed it was valid.Reject the operation early if not in station mode or not associated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix vmalloc out-of-bounds write in fast_imageblitThis issue triggers when a userspace program does an ioctlFBIOPUT_CON2FBMAP by passing console number and frame buffer number.Ideally this maps console to frame buffer and updates the screen ifconsole is visible.As part of mapping it has to do resize of console according to framebuffer info. if this resize fails and returns from vc_do_resize() andcontinues further. At this point console and new frame buffer are mappedand sets display vars. Despite failure still it continue to proceedupdating the screen at later stages where vc_data is related to previousframe buffer and frame buffer info and display vars are mapped to newframe buffer and eventully leading to out-of-bounds write infast_imageblit(). This bheviour is excepted only when fg_console isequal to requested console which is a visible console and updates screenwith invalid struct references in fbcon_putcs().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add validation for ring_len paramThe `ring_len` parameter provided by the virtual function (VF)is assigned directly to the hardware memory context (HMC) withoutany validation.To address this, introduce an upper boundary check for both Tx and Rxqueue lengths. The maximum number of descriptors supported by thehardware is 8k-32.Additionally, enforce alignment constraints: Tx rings must be a multipleof 8, and Rx rings must be a multiple of 32.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: Defer ip_vs_ftp unregister during netns cleanupOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftpbefore connections with valid cp->app pointers are flushed, leading to ause-after-free.Fix this by introducing a global `exiting_module` flag, set to true inip_vs_ftp_exit() before unregistering the pernet subsystem. In__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netnscleanup (when exiting_module is false) and defer it to__ip_vs_cleanup_batch(), which unregisters all apps after all connectionsare flushed. If called during module exit, unregister ip_vs_ftpimmediately.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().syzbot reported the splat below in tcp_conn_request(). [0]If a listener is close()d while a TFO socket is being processed intcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->skand calls inet_child_forget(), which calls tcp_disconnect() for theTFO socket.After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),where reqsk_put() is called due to !reqsk->sk.Then, reqsk_fastopen_remove() in tcp_conn_request() decrements thelast req->rsk_refcnt and frees reqsk, and __reqsk_free() at thedrop_and_free label causes the refcount underflow for the listenerand double-free of the reqsk.Let's remove reqsk_fastopen_remove() in tcp_conn_request().Note that other callers make sure tp->fastopen_rsk is not NULL.[0]:refcount_t: underflow; use-after-free.WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)Modules linked in:CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0Call Trace: tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_conn_freeBUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410net/bluetooth/sco.c:107Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci13 hci_cmd_sync_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the 'subtag' struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libicu52_1 < 52.1-8.16.1 (version in image is 52.1-8.13.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: fsl-usb: Fix use-after-free in delayed work during device removalThe delayed work item otg_event is initialized in fsl_otg_conf() andscheduled under two conditions:1. When a host controller binds to the OTG controller.2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via fsl_otg_remove():the fsl_otg instance may be freed while the delayed work is still pendingor executing. This leads to use-after-free when the work functionfsl_otg_event() accesses the already freed memory.The problematic scenario:(detach thread) | (delayed work)fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove()before deallocating the fsl_otg structure. This ensures the delayed workis properly canceled and completes execution prior to memory deallocation.This bug was identified through static analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add VLAN id validation before usingCurrently, the VLAN id may be used without validation whenreceive a VLAN configuration mailbox from VF. The length ofvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may causeout-of-bounds memory access once the VLAN id is bigger thanor equal to VLAN_N_VID.Therefore, VLAN id needs to be checked to ensure it is withinthe range of VLAN_N_VID.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: buffer.c in named in ISC BIND 9.10.x before 9.10.3-P3, when debug logging is enabled, allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon exit, or daemon crash) or possibly have unspecified other impact via (1) OPT data or (2) an ECS option.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils > 0-0 (version in image is 9.11.22-3.49.1).
-
Description: named in ISC BIND 9.x before 9.9.8-P4 and 9.10.x before 9.10.3-P4 does not properly handle DNAME records when parsing fetch reply messages, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a malformed packet to the rndc (aka control channel) interface, related to alist.c and sexpr.c.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: resolver.c in named in ISC BIND 9.10.x before 9.10.3-P4, when DNS cookies are enabled, allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via a malformed packet with more than one cookie option.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils > 0-0 (version in image is 9.11.22-3.49.1).
-
Description: Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- openssh < 7.2p2-81.26.1 (version in image is 7.2p2-81.4.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: storage: sddr55: Reject out-of-bound new_pbaDiscovered by Atuin - Automated Vulnerability Discovery Engine.new_pba comes from the status packet returned after each write.A bogus device could report values beyond the block count derivedfrom info->capacity, letting the driver walk off the end ofpba_to_lba[] and corrupt heap memory.Reject PBAs that exceed the computed block count and fail thetransfer so we avoid touching out-of-range mapping entries.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_6m1_0 < 3.6.15-84.1 (version in image is 3.6.15-49.1).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpng16-16 > 0-0 (version in image is 1.6.8-15.5.2).
-
Description: OpenLDAP Lightning Memory-Mapped Database (LMDB) versions up to and including 0.9.14, prior to commit 8e1fda8, contain a heap buffer underflow in the readline() function of mdb_load. When processing malformed input containing an embedded NUL byte, an unsigned offset calculation can underflow and cause an out-of-bounds read of one byte before the allocated heap buffer. This can cause mdb_load to crash, leading to a limited denial-of-service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libldap-2_4-2 > 0-0 (version in image is 2.4.41-22.19.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't query the device logical block size multiple timesDevices block sizes may change. One of these cases is a loop device byusing ioctl LOOP_SET_BLOCK_SIZE.While this may cause other issues like IO being rejected, in the case ofhfsplus, it will allocate a block by using that size and potentially writeout-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and thelatter function reads a different io_size.Using a new min_io_size initally set to sb_min_blocksize works for thepurposes of the original fix, since it will be set to the max betweenHFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use themax between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is notinitialized.Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024and 4096.The produced KASAN report before the fix looks like this:[ 419.944641] ==================================================================[ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a[ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678[ 419.947612][ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84[ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 419.950035] Call Trace:[ 419.950384] [ 419.950676] dump_stack_lvl+0x57/0x78[ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a[ 419.951830] print_report+0x14c/0x49e[ 419.952361] ? __virt_addr_valid+0x267/0x278[ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d[ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a[ 419.954231] kasan_report+0x89/0xb0[ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a[ 419.955367] hfsplus_read_wrapper+0x659/0xa0a[ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10[ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9[ 419.957214] ? _raw_spin_unlock+0x1a/0x2e[ 419.957772] hfsplus_fill_super+0x348/0x1590[ 419.958355] ? hlock_class+0x4c/0x109[ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10[ 419.959499] ? __pfx_string+0x10/0x10[ 419.960006] ? lock_acquire+0x3e2/0x454[ 419.960532] ? bdev_name.constprop.0+0xce/0x243[ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10[ 419.961799] ? pointer+0x3f0/0x62f[ 419.962277] ? __pfx_pointer+0x10/0x10[ 419.962761] ? vsnprintf+0x6c4/0xfba[ 419.963178] ? __pfx_vsnprintf+0x10/0x10[ 419.963621] ? setup_bdev_super+0x376/0x3b3[ 419.964029] ? snprintf+0x9d/0xd2[ 419.964344] ? __pfx_snprintf+0x10/0x10[ 419.964675] ? lock_acquired+0x45c/0x5e9[ 419.965016] ? set_blocksize+0x139/0x1c1[ 419.965381] ? sb_set_blocksize+0x6d/0xae[ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10[ 419.966179] mount_bdev+0x12f/0x1bf[ 419.966512] ? __pfx_mount_bdev+0x10/0x10[ 419.966886] ? vfs_parse_fs_string+0xce/0x111[ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10[ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10[ 419.968073] legacy_get_tree+0x104/0x178[ 419.968414] vfs_get_tree+0x86/0x296[ 419.968751] path_mount+0xba3/0xd0b[ 419.969157] ? __pfx_path_mount+0x10/0x10[ 419.969594] ? kmem_cache_free+0x1e2/0x260[ 419.970311] do_mount+0x99/0xe0[ 419.970630] ? __pfx_do_mount+0x10/0x10[ 419.971008] __do_sys_mount+0x199/0x1c9[ 419.971397] do_syscall_64+0xd0/0x135[ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 419.972233] RIP: 0033:0x7c3cb812972e[ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48[ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5[ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e[ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shadow < 4.2.1-36.15.1 (version in image is 4.2.1-36.6.1).
-
Description: In Sudo through 1.8.29, an attacker with access to a Runas ALL sudoer account can impersonate a nonexistent user by invoking sudo with a numeric uid that is not associated with any user. NOTE: The software maintainer believes that this is not a vulnerability because running a command via sudo as a user not present in the local password database is an intentional feature. Because this behavior surprised some users, sudo 1.8.30 introduced an option to enable/disable this behavior with the default being disabled. However, this does not change the fact that sudo was behaving as intended, and as documented, in earlier versions
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sudo > 0-0 (version in image is 1.8.27-4.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: custom_method: fix potential use-after-free issueIn cm_write(), buf is always freed when reaching the end of thefunction. If the requested count is less than table.length, theallocated buffer will be freed but subsequent calls to cm_write() willstill try to access it.Remove the unconditional kfree(buf) at the end of the function andset the buf to NULL in the -EINVAL error path to match the rest offunction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethernet:enic: Fix a use after free bug in enic_hard_start_xmitIn enic_hard_start_xmit, it calls enic_queue_wq_skb(). Insideenic_queue_wq_skb, if some error happens, the skb will be freedby dev_kfree_skb(skb). But the freed skb is still used inskb_tx_timestamp(skb).My patch makes enic_queue_wq_skb() return error and goto spin_unlock()incase of error. The solution is provided by Govind.See https://lkml.org/lkml/2021/4/30/961.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Stop looking for coalesced MMIO zones if the bus is destroyedAbort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev()fails to allocate memory for the new instance of the bus. If it can'tinstantiate a new bus, unregister_dev() destroys all devices _except_ thetarget device. But, it doesn't tell the caller that it obliterated thebus and invoked the destructor for all devices that were on the bus. Inthe coalesced MMIO case, this can result in a deleted list entrydereference due to attempting to continue iterating on coalesced_zonesafter future entries (in the walk) have been deleted.Opportunistically add curly braces to the for-loop, which encompassesmany lines but sneaks by without braces due to the guts being a singleif statement.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCUIf allocating a new instance of an I/O bus fails when unregistering adevice, wait to destroy the device until after all readers are guaranteedto see the new null bus. Destroying devices before the bus is nullifiedcould lead to use-after-free since readers expect the devices on theirreference of the bus to remain valid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge/panel: Cleanup connector on bridge detachIf we don't call drm_connector_cleanup() manually inpanel_bridge_detach(), the connector will be cleaned up with the otherDRM objects in the call to drm_mode_config_cleanup(). However, since ourdrm_connector is devm-allocated, by the time drm_mode_config_cleanup()will be called, our connector will be long gone. Therefore, theconnector must be cleaned up when the bridge is detached to avoiduse-after-free conditions.v2: Cleanup connector only if it was createdv3: Add FIXMEv4: (Use connector->dev) directly in if() block
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: mmio: Fix use-after-free Read in kvm_vm_ioctl_unregister_coalesced_mmioBUG: KASAN: use-after-free in kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183Read of size 8 at addr ffff0000c03a2500 by task syz-executor083/4269CPU: 5 PID: 4269 Comm: syz-executor083 Not tainted 5.10.0 #7Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132 show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x110/0x164 lib/dump_stack.c:118 print_address_description+0x78/0x5c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report+0x148/0x1e4 mm/kasan/report.c:562 check_memory_region_inline mm/kasan/generic.c:183 [inline] __asan_load8+0xb4/0xbc mm/kasan/generic.c:252 kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall arch/arm64/kernel/syscall.c:48 [inline] el0_svc_common arch/arm64/kernel/syscall.c:158 [inline] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670Allocated by task 4269: stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121 kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc+0xdc/0x120 mm/kasan/common.c:461 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475 kmem_cache_alloc_trace include/linux/slab.h:450 [inline] kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:664 [inline] kvm_vm_ioctl_register_coalesced_mmio+0x78/0x1cc arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:146 kvm_vm_ioctl+0x7e8/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3746 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall arch/arm64/kernel/syscall.c:48 [inline] el0_svc_common arch/arm64/kernel/syscall.c:158 [inline] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670Freed by task 4269: stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121 kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x38/0x6c mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355 __kasan_slab_free+0x124/0x150 mm/kasan/common.c:422 kasan_slab_free+0x10/0x1c mm/kasan/common.c:431 slab_free_hook mm/slub.c:1544 [inline] slab_free_freelist_hook mm/slub.c:1577 [inline] slab_free mm/slub.c:3142 [inline] kfree+0x104/0x38c mm/slub.c:4124 coalesced_mmio_destructor+0x94/0xa4 arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:102 kvm_iodevice_destructor include/kvm/iodev.h:61 [inline] kvm_io_bus_unregister_dev+0x248/0x280 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:4374 kvm_vm_ioctl_unregister_coalesced_mmio+0x158/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:186 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall arch/arm64/kernel/sys---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fieldsOverflowing either addrlimit or bytes_togo can allow userspace to triggera buffer overflow of kernel memory. Check for overflows in all the placesdoing math on user controlled buffers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fslWhen the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ==================================================================The triggering of the BUG is shown in the following stack:driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host)The iounmap(host_priv->hcr_base) and kfree(host_priv) functions shouldnot be executed in drv->remove. These functions should be executed inhost_stop after port_stop. Therefore, we move these functions to thenew function sata_fsl_host_stop and bind the new function to host_stop.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.189.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free after failure to create a snapshotAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure andthen attach it to the transaction's list of pending snapshots. After thatwe call btrfs_commit_transaction(), and if that returns an error we jumpto 'fail' label, where we kfree() the pending snapshot structure. This canresult in a later use-after-free of the pending snapshot:1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots;2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list;3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free.This issue could actually be detected by smatch, which produced thefollowing warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from listSo fix this by not having the snapshot creation ioctl directly add thepending snapshot to the transaction's list. Instead add the pendingsnapshot to the transaction handle, and then at btrfs_commit_transaction()we add the snapshot to the list only when we can guarantee that any errorreturned after that point will result in a transaction abort, in whichcase the ioctl code can safely free the pending snapshot and no one canaccess it anymore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix stale file descriptors on failed usercopyA failing usercopy of the fence_rep object will lead to a stale entry inthe file descriptor table as put_unused_fd() won't release it. Thisenables userland to refer to a dangling 'file' object through that stillvalid file descriptor, leading to all kinds of use-after-freeexploitation scenarios.Fix this by deferring the call to fd_install() until after the usercopyhas succeeded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Free buffers when a used dynamic event is removedAfter 65536 dynamic events have been added and removed, the "type" fieldof the event then uses the first type number that is available (notcurrently used by other events). A type number is the identifier of thebinary blobs in the tracing ring buffer (known as events) to map them tologic that can parse the binary blob.The issue is that if a dynamic event (like a kprobe event) is traced andis in the ring buffer, and then that event is removed (because it isdynamic, which means it can be created and destroyed), if another dynamicevent is created that has the same number that new event's logic onparsing the binary blob will be used.To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # doneFor every iteration of the above, the writing to the kprobe_events willremove the old event and create a new one (with the same format) andincrease the type number to the next available on until the type numberreaches over 65535 which is the max number for the 16 bit type. After itreaches that number, the logic to allocate a new number simply looks forthe next available number. When an dynamic event is removed, that numberis then available to be reused by the next dynamic event created. That is,once the above reaches the max number, the number assigned to the event inthat loop will remain the same.Now that means deleting one dynamic event and created another will reusethe previous events type number. This is where bad things can happen.After the above loop finishes, the kprobes/foo event which reads thedo_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enableNow if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_eventsAnd now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="���������������������������������������---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drbd: Fix five use after free bugs in get_initial_stateIn get_initial_state, it calls notify_initial_state_done(skb,..) ifcb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),the skb will be freed by nlmsg_free(skb).Then get_initial_state will goto out and the freed skb will be used byreturn value skb->len, which is a uaf bug.What's worse, the same problem goes even further: skb can also befreed in the notify_*_state_change -> notify_*_state calls below.Thus 4 additional uaf bugs happened.My patch lets the problem callee functions: notify_initial_state_doneand notify_*_state_change return an error code if errors happen.So that the error codes could be propagated and the uaf bugs can be avoid.v2 reports a compilation warning. This v3 fixed this warning and builtsuccessfully in my local environment with no additional warnings.v2: https://lore.kernel.org/patchwork/patch/1435218/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libfc: Fix use after free in fc_exch_abts_resp()fc_exch_release(ep) will decrease the ep's reference count. When thereference count reaches zero, it is freed. But ep is still used in thefollowing code, which will lead to a use after free.Return after the fc_exch_release() call to avoid use after free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid cycles in directory h-treeA maliciously corrupted filesystem can contain cycles in the h-treestored inside a directory. That can easily lead to the kernel corruptingtree nodes that were already verified under its hands while doing a nodesplit and consequently accessing unallocated memory. Fix the problem byverifying traversed block numbers are unique.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md-raid10: fix KASAN warningThere's a KASAN warning in raid10_remove_disk when running the lvmtest lvconvert-raid-reshape.sh. We fix this warning by verifying that thevalue "number" is valid.BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? raid10_remove_disk+0x61/0x2a0 [raid10] kasan_report+0xa8/0xe0 ? raid10_remove_disk+0x61/0x2a0 [raid10] raid10_remove_disk+0x61/0x2a0 [raid10]Buffer I/O error on dev dm-76, logical block 15344, async page read ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0 remove_and_add_spares+0x367/0x8a0 [md_mod] ? super_written+0x1c0/0x1c0 [md_mod] ? mutex_trylock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0xcf/0x3360 [raid10] ? sched_clock_cpu+0x185/0x1a0 ? rb_erase+0x4d4/0x620 ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid10_sync_request+0x36c0/0x36c0 [raid10] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Allocated by task 124495: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 setup_conf+0x140/0x5c0 [raid10] raid10_run+0x4cd/0x740 [raid10] md_run+0x6f9/0x1300 [md_mod] raid_ctr+0x2531/0x4ac0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140L __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300)The buggy address belongs to the physical page:page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3chead:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0flags: 0x4000000000010200(slab|head|zone=2)raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Fix error code path in acpi_ds_call_control_method()A use-after-free in acpi_ps_parse_aml() after a failing invocaion ofacpi_ds_call_control_method() is reported by KASAN [1] and codeinspection reveals that next_walk_state pushed to the thread byacpi_ds_create_walk_state() is freed on errors, but it is not poppedfrom the thread beforehand. Thus acpi_ds_get_current_walk_state()called by acpi_ps_parse_aml() subsequently returns it as the newwalk state which is incorrect.To address this, make acpi_ds_call_control_method() callacpi_ds_pop_walk_state() to pop next_walk_state from the thread beforereturning an error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: A buffer overflow was found in Shim in the 32-bit system. The overflow happens due to an addition operation involving a user-controlled value parsed from the PE binary being used by Shim. This value is further used for memory allocation operations, leading to a heap-based buffer overflow. This flaw causes memory corruption and can lead to a crash or data integrity issues during the boot phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow timeout for anonymous setsNever used from userspace, disallow these parameters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: ipc: Fix potential use-after-free in work functionWhen a reset notify IPC message is received, the ISR schedules a workfunction and passes the ISHTP device to it via a global pointerishtp_dev. If ish_probe() fails, the devm-managed device resourcesincluding ishtp_dev are freed, but the work is not cancelled, causing ause-after-free when the work function tries to access ishtp_dev. Usedevm_work_autocancel() instead, so that the work is automaticallycancelled if probe fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lwt: Fix return values of BPF xmit opsBPF encap ops can return different types of positive values, such likeNET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from functionskb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such returnvalues would be treated implicitly as LWTUNNEL_XMIT_CONTINUE inip(6)_finish_output2. When this happens, skbs that have been freed wouldcontinue to the neighbor subsystem, causing use-after-free bug andkernel crashes.To fix the incorrect behavior, skb_do_redirect return values can besimply discarded, the same as tc-egress behavior. On the other hand,bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTUinformation. Thus convert its return values to avoid the conflict withLWTUNNEL_XMIT_CONTINUE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: Avoid nf_ct_helper_hash uses after freeIf nf_conntrack_init_start() fails (for example due to aregister_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()clean-up path frees the nf_ct_helper_hash map.When built with NF_CONNTRACK=y, further netfilter modules (e.g:netfilter_conntrack_ftp) can still be loaded and callnf_conntrack_helpers_register(), independently of whether nf_conntrackinitialized correctly. This accesses the nf_ct_helper_hash danglingpointer and causes a uaf, possibly leading to random memory corruption.This patch guards nf_conntrack_helper_register() from accessing a freedor uninitialized nf_ct_helper_hash pointer and fixes possibleuses-after-free when loading a conntrack module.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix stack corruptionWhen tc filters are first added to a net device, the corresponding localport gets bound to an ACL group in the device. The group contains a listof ACLs. In turn, each ACL points to a different TCAM region where thefilters are stored. During forwarding, the ACLs are sequentiallyevaluated until a match is found.One reason to place filters in different regions is when they are addedwith decreasing priorities and in an alternating order so that twoconsecutive filters can never fit in the same region because of theirkey usage.In Spectrum-2 and newer ASICs the firmware started to report that themaximum number of ACLs in a group is more than 16, but the layout of theregister that configures ACL groups (PAGT) was not updated to accountfor that. It is therefore possible to hit stack corruption [1] in therare case where more than 16 ACLs in a group are required.Fix by limiting the maximum ACL group size to the minimum between whatthe firmware reports and the maximum ACLs that fit in the PAGT register.Add a test case to make sure the machine does not crash when thiscondition is hit.[1]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120[...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow anonymous set with timeout flagAnonymous sets are never used with timeout from userspace, reject this.Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: do not free live elementPablo reports a crash with large batches of elements with aback-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.Looking at the remove function there is a chance that we will drop arule that maps to a non-deactivated element.Removal happens in two steps, first we do a lookup for key k and return theto-be-removed element and mark it as inactive in the next generation.Then, in a second step, the element gets removed from the set/map.The _remove function does not work correctly if we have more than oneelement that share the same key.This can happen if we insert an element into a set when the set alreadyholds an element with same key, but the element mapping to the existingkey has timed out or is not active in the next generation.In such case its possible that removal will unmap the wrong element.If this happens, we will leak the non-deactivated element, it becomesunreachable.The element that got deactivated (and will be freed later) willremain reachable in the set data structure, this can result ina crash when such an element is retrieved during lookup (stalepointer).Add a check that the fully matching key does in fact map to the elementthat we have marked as inactive in the deactivation step.If not, we need to continue searching.Add a bug/warn trap at the end of the function as well, the removefunction must not ever be called with an invisible/unreachable/non-existentelement.v2: avoid uneeded temporary variable (Stefano)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: use timestamp to check for set element timeoutAdd a timestamp field at the beginning of the transaction, store itin the nftables per-netns area.Update set backend .insert, .deactivate and sync gc path to use thetimestamp, this avoids that an element expires while control planetransaction is still unfinished..lookup and .update, which are used from packet path, still use thecurrent time to check if the element has expired. And .get path and dumpalso since this runs lockless under rcu read size lock. Then, there isasync gc which also needs to check the current time since it runsasynchronously from a workqueue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: fix possible out-of-bounds in gsm0_receive()Assuming the following:- side A configures the n_gsm in basic option mode- side B sends the header of a basic option mode frame with data length 1- side A switches to advanced option mode- side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode.- side A switches to basic option mode- side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.Fix this by changing gsm->count to gsm->len comparison from equal to lessthan. Also add upper limit checks against the constant MAX_MRU ingsm0_receive() and gsm1_receive() to harden against memory corruption ofgsm->len and gsm->mru.All other checks remain as we still need to limit the data according to theuser configuration and actual payload size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix out-of-bounds access in ops_initnet_alloc_generic is called by net_alloc, which is called without anylocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. Itis read twice, first to allocate an array, then to set s.len, which islater used to limit the bounds of the array access.It is possible that the array is allocated and another thread isregistering a new pernet ops, increments max_gen_ptrs, which is then usedto set s.len with a larger than allocated length for the variable array.Fix it by reading max_gen_ptrs only once in net_alloc_generic. Ifmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Ensure the copied buf is NUL terminatedCurrently, we allocate a count-sized kernel buffer and copy count fromuserspace to that buffer. Later, we use kstrtouint on this buffer but wedon't ensure that the string is terminated inside the buffer, this canlead to OOB read when using kstrtouint. Fix this issue by usingmemdup_user_nul instead of memdup_user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_triggerWhen the cpu5wdt module is removing, the origin code uses del_timer() tode-activate the timer. If the timer handler is running, del_timer() couldnot stop it and will return directly. If the port region is released byrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()to write into the region that is released, the use-after-free bug willhappen.Change del_timer() to timer_shutdown_sync() in order that the timer handlercould be finished before the port region is released.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: Fix use-after-free when removing resource in vmci_resource_remove()When removing a resource from vmci_resource_table invmci_resource_remove(), the search is performed using the resourcehandle by comparing context and resource fields.It is possible though to create two resources with different typesbut same handle (same context and resource fields).When trying to remove one of the resources, vmci_resource_remove()may not remove the intended one, but the object will still be freedas in the case of the datagram type in vmci_datagram_destroy_handle().vmci_resource_table will still hold a pointer to this freed resourceleading to a use-after-free vulnerability.BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0This change ensures the type is also checked when removingthe resource from vmci_resource_table in vmci_resource_remove().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix helper writes to read-only mapsLonial found an issue that despite user- and BPF-side frozen BPF map(like in case of .rodata), it was still possible to write into it froma BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}as arguments.In check_func_arg() when the argument is as mentioned, the meta->raw_modeis never set. Later, check_helper_mem_access(), under the case ofPTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for thesubsequent call to check_map_access_type() and given the BPF map isread-only it succeeds.The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINITwhen results are written into them as opposed to read out of them. Thelatter indicates that it's okay to pass a pointer to uninitialized memoryas the memory is written to anyway.However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEMjust with additional alignment requirement. So it is better to just getrid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse thefixed size memory types. For this, add MEM_ALIGNED to additionally ensurealignment given these helpers write directly into the args via *
= val.The .arg*_size has been initialized reflecting the actual sizeof(*).MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotatedargument types, since in !MEM_FIXED_SIZE cases the verifier does not knowthe buffer size a priori and therefore cannot blindly write * = val.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix usage slab after free[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020[ +0.000016] Call Trace:[ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0[ +0.000017] print_report+0xce/0x5f0[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] ? srso_return_thunk+0x5/0x5f[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] kasan_report+0xbe/0x110[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000023] __asan_report_load8_noabort+0x14/0x30[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? enable_work+0x124/0x220[ +0.000015] ? __pfx_enable_work+0x10/0x10[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? free_large_kmalloc+0x85/0xf0[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched][ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu][ +0.000735] ? __kasan_check_read+0x11/0x20[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu][ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu][ +0.000679] ? mutex_unlock+0x80/0xe0[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu][ +0.000662] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? mutex_unlock+0x80/0xe0[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu][ +0.000663] drm_minor_release+0xc9/0x140 [drm][ +0.000081] drm_release+0x1fd/0x390 [drm][ +0.000082] __fput+0x36c/0xad0[ +0.000018] __fput_sync+0x3c/0x50[ +0.000014] __x64_sys_close+0x7d/0xe0[ +0.000014] x64_sys_call+0x1bc6/0x2680[ +0.000014] do_syscall_64+0x70/0x130[ +0.000014] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190[ +0.000015] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit+0x43/0x50[ +0.000012] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? exc_page_fault+0x7c/0x110[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ +0.000014] RIP: 0033:0x7ffff7b14f67[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040[ +0.000020] [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:[ +0.000014] kasan_save_stack+0x28/0x60[ +0.000008] kasan_save_track+0x18/0x70[ +0.000007] kasan_save_alloc_info+0x38/0x60[ +0.000007] __kasan_kmalloc+0xc1/0xd0[ +0.000007] kmalloc_trace_noprof+0x180/0x380[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched][ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu][ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu][ +0.000662] amdgpu_pci_p---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: adv7511: Fix use-after-free in adv7533_attach_dsi()The host_node pointer was assigned and freed in adv7533_parse_dt(), andlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issueby dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()in error path of probe() and also in the remove().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: Disallow replacing of child qdisc from one parent to anotherLion Ackermann was able to create a UAF which can be abused for privilegeescalation with the following scriptStep 1. create root qdisctc qdisc add dev lo root handle 1:0 drrstep2. a class for packet aggregation do demonstrate uaftc class add dev lo classid 1:1 drrstep3. a class for nestingtc class add dev lo classid 1:2 drrstep4. a class to graft qdisc totc class add dev lo classid 1:3 drrstep5.tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024step6.tc qdisc add dev lo parent 1:2 handle 3:0 drrstep7.tc class add dev lo classid 3:1 drrstep 8.tc qdisc add dev lo parent 3:1 handle 4:0 pfifostep 9. Display the class/qdisc layouttc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kbtc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2step10. trigger the bug <=== prevented by this patchtc qdisc replace dev lo parent 1:3 handle 4:0step 11. Redisplay again the qdiscs/classestc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kbtc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2Observe that a) parent for 4:0 does not change despite the replace request.There can only be one parent. b) refcount has gone up by two for 4:0 andc) both class 1:3 and 3:1 are pointing to it.Step 12. send one packet to plugecho "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))step13. send one packet to the grafted fifoecho "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))step14. lets trigger the uaftc class delete dev lo classid 1:3tc class delete dev lo classid 1:1The semantics of "replace" is for a del/add _on the same node_ and nota delete from one node(3:1) and add to another node (1:3) as in step10.While we could "fix" with a more complex approach there could beconsequences to expectations so the patch takes the preventive approach of"disallow such config".Joint work with Lion Ackermann
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: pktgen: fix access outside of user given buffer in pktgen_thread_write()Honour the user given buffer size for the strn_len() calls (otherwisestrn_len() will access memory outside of the user given buffer).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpolkit0 < 0.113-5.30.1 (version in image is 0.113-5.27.1).
-
Description: "" In X.Org X Server 1.20.4, there is a stack-based buffer overflow in the function XQueryKeymap. For example, by sending ct.c_char 1000 times, an attacker can cause a denial of service (application crash) or possibly have unspecified other impact. Note: It is disputed if the X.Org X Server is involved or if there is a stack overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libX11-6 > 0-0 (version in image is 1.6.2-12.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc/libmasm/module: Fix two use after free in ibmasm_init_oneIn ibmasm_init_one, it calls ibmasm_init_remote_input_dev().Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev areallocated by input_allocate_device(), and assigned tosp->remote.mouse_dev and sp->remote.keybd_dev respectively.In the err_free_devices error branch of ibmasm_init_one,mouse_dev and keybd_dev are freed by input_free_device(), and returnerror. Then the execution runs into error_send_message error branchof ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is calledto unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev.My patch add a "error_init_remote" label to handle the error ofibmasm_init_remote_input_dev(), to avoid the uaf bugs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()The if statement: if (port >= DSAF_GE_NUM) return;limits the value of port less than DSAF_GE_NUM (i.e., 8).However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).To fix this possible array overflow, we first check port and if it isgreater than or equal to DSAF_MAX_PORT_NUM, the function returns.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixupax88179_rx_fixup() contains several out-of-bounds accesses that can betriggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data.I have tested that this can be used by a malicious USB device to send abogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in responsethat contains random kernel heap data.It's probably also possible to get OOB writes from this on alittle-endian system somehow - maybe by triggering skb_cow() via IPoptions processing -, but I haven't tested that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:CDC-NCM: avoid overflow in sanity checkingA broken device may give an extreme offset like 0xFFF0and a reasonable length for a fragment. In the sanitycheck as formulated now, this will create an integeroverflow, defeating the sanity check. Both offsetand offset + len need to be checked in such a mannerthat no overflow can occur.And those quantities should be unsigned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: amd8111: Fix PCI device reference count leakfor_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULLinput parameter, there is no problem for the 'Device not found' branch.For the normal path, add pci_dev_put() in amd_gpio_exit().
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in l2tp_ip6_sendmsgWhen len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will beoverflow. To fix, we can follow what udpv6 does and subtract thetranshdrlen from the max.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in __ip6_append_dataResurrect ubsan overflow checks and ubsan report this warning,fix it by change the variable [length] type to size_t.UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:192147479552 + 8567 cannot be represented in type 'int'CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170Changes since v1:-Change the variable [length] type to unsigned, as Eric Dumazet suggested.Changes since v2:-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.Changes since v3:-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, asJakub Kicinski suggested.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers:md:fix a potential use-after-free bugIn line 2884, "raid5_release_stripe(sh);" drops the reference to sh andmay cause sh to be released. However, sh is subsequently used in lines2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in anuse-after-free bug.It can be fixed by moving "raid5_release_stripe(sh);" to the bottom ofthe function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm raid: fix address sanitizer warning in raid_resumeThere is a KASAN warning in raid_resume when running the lvm testlvconvert-raid.sh. The reason for the warning is that mddev->raid_disksis greater than rs->raid_disks, so the loop touches one entry beyondthe allocated length.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inodeThere are many places that will get unhappy (and crash) when ext4_iget()returns a bad inode. However, if iget the boot loader inode, allows a badinode to be returned, because the inode may not be initialized. Thismechanism can be used to bypass some checks and cause panic. To solve thisproblem, we add a special iget flag EXT4_IGET_BAD. Only with this flagwe'd be returning bad inode from ext4_iget(), otherwise we always returnthe error code if the inode is bad inode.(suggested by Jan Kara)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix OOB Read in __hfs_brec_findSyzbot reported a OOB read bug:==================================================================BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190fs/hfs/string.c:84Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted6.1.0-rc6-syzkaller-00308-g644e9524388a #0Workqueue: writeback wb_workfn (flush-7:0)Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75 hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138 hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462 write_inode fs/fs-writeback.c:1440 [inline]If the input inode of hfs_write_inode() is incorrect:struct inode struct hfs_inode_info struct hfs_cat_key struct hfs_name u8 len # len is greater than HFS_NAMELEN(31) which is themaximum length of an HFS filenameOOB read occurred:hfs_write_inode() hfs_brec_find() __hfs_brec_find() hfs_cat_keycmp() hfs_strcmp() # OOB read occurred due to len is too largeFix this by adding a Check on len in hfs_write_inode() before callinghfs_brec_find().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: aqc111: check packet for fixup for true limitIf a device sends a packet that is inbetween 0and sizeof(u64) the value passed to skb_trim()as length will wrap around ending up as some verylarge value.The driver will then proceed to parse the headerlocated at that position, which will either oops orprocess some random value.The fix is to check against sizeof(u64) rather than0, which the driver currently does. The issue existssince the introduction of the driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7For pptable structs that use flexible array sizes, use flexible arrays.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and TongaFor pptable structs that use flexible array sizes, use flexible arrays.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atl1c: Work around the DMA RX overflow issueThis is based on alx driver commit 881d0327db37 ("net: alx: Work aroundthe DMA RX overflow issue").The alx and atl1c drivers had RX overflow error which was why a customallocator was created to avoid certain addresses. The simpler workaroundthen created for alx driver, but not for atl1c due to lack of tester.Instead of using a custom allocator, check the allocated skb address anduse skb_reserve() to move away from problematic 0x...fc0 address.Tested on AR8131 on Acer 4540.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: Correct devm device reference for hidinput input_dev nameReference the HID device rather than the input device for the devmallocation of the input_dev name. Referencing the input_dev would lead to ause-after-free when the input_dev was unregistered and subsequently fires auevent that depends on the name. At the point of firing the uevent, thename would be freed by devres management.Use devm_kasprintf to simplify the logic for allocating memory andformatting the input_dev name string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential race when tree connecting ipcProtect access of TCP_Server_Info::hostname when building the ipc treename as it might get freed in cifsd thread and thus causing anuse-after-free bug in __tree_connect_dfs_target(). Also, while at it,update status of IPC tcon on success and then avoid any extra treeconnects.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtraceA received TKIP key may be up to 32 bytes because it may containMIC rx/tx keys too. These are not used by iwl and copying theseover overflows the iwl_keyinfo.key field.Add a check to not copy more data to iwl_keyinfo.key then will fit.This fixes backtraces like this one: memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16) WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm] Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017 RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm] Call Trace: iwl_set_dynamic_key+0x1f0/0x220 [iwldvm] iwlagn_mac_set_key+0x1e4/0x280 [iwldvm] drv_set_key+0xa4/0x1b0 [mac80211] ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211] ieee80211_key_replace+0x22d/0x8e0 [mac80211]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rxFor the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoiduninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() shouldvalidate pkt_len before accessing the SKB.For example, the obtained SKB may have been badly constructed withpkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdrbut after being processed in ath9k_htc_rx_msg() and passed toath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMIcommand header which should be located inside its data payload.Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninitmemory can be referenced.Tested on Qualcomm Atheros Communications AR9271 802.11n .Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet: inet_defrag: prevent sk release while still in useip_local_out() and other functions can pass skb->sk as function argument.If the skb is a fragment and reassembly happens before such function callreturns, the sk must not be released.This affects skb fragments reassembled via netfilter or similarmodules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used.Eric suggested to stash sk in fragment queue and made an initial patch.However there is a problem with this:If skb is refragmented again right after, ip_do_fragment() will copyhead->sk to the new fragments, and sets up destructor to sock_wfree.IOW, we have no choice but to fix up sk_wmem accouting to reflect thefully reassembled skb, else wmem will underflow.This change moves the orphan down into the core, to last possible moment.As ip_defrag_offset is aliased with sk_buff->sk member, we must move theoffset into the FRAG_CB, else skb->sk gets clobbered.This allows to delay the orphaning long enough to learn if the skb hasto be queued or if the skb is completing the reasm queue.In the former case, things work as before, skb is orphaned. This issafe because skb gets queued/stolen and won't continue past reasm engine.In the latter case, we will steal the skb->sk reference, reattach it tothe head skb, and fix up wmem accouting when inet_frag inflates truesize.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: null check for nla_nest_startnla_nest_start() may fail and return NULL. Insert a check and set errnobased on other call sites within the same source code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return valuecpufreq_cpu_get may return NULL. To avoid NULL-dereference check itand return 0 in case of error.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firewire: nosy: ensure user_length is taken into account when fetching packet contentsEnsure that packet_buffer_get respects the user_length provided. Ifthe length of the head packet exceeds the user_length, packet_buffer_getwill now return 0 to signify to the user that no data were readand a larger buffer size is required. Helps prevent user space overflows.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Use access_width over bit_width for system memory accessesTo align with ACPI 6.3+, since bit_width can be any 8-bit value, itcannot be depended on to be always on a clean 8b boundary. This wasuncovered on the Cobalt 100 platform.SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8Instead, use access_width to determine the size and use the offset andwidth to shift and mask the bits to read/write out. Make sure to add acheck for system memory since pcc redefines the access_width tosubspace id.If access_width is not set, then fall back to using bit_width.[ rjw: Subject and changelog edits, comment adjustments ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memoryThere is a potential out-of-bounds access when using test_bit() on a singleword. The test_bit() and set_bit() functions operate on long values, andwhen testing or setting a single word, they can exceed the wordboundary. KASAN detects this issue and produces a dump: BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965For full log, please look at [1].Make the allocation at least the size of sizeof(unsigned long) so thatset_bit() and test_bit() have sufficient room for read/write operationswithout overwriting unallocated memory.[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Handle TD clearing for multiple streams caseWhen multiple streams are in use, multiple TDs might be in flight whenan endpoint is stopped. We need to issue a Set TR Dequeue Pointer foreach, to ensure everything is reset properly and the caches cleared.Change the logic so that any N>1 TDs found active for different streamsare deferred until after the first one is processed, callingxhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() toqueue another command until we are done with all of them. Also changethe error/"should never happen" paths to ensure we at least clear anyaffected TDs, even if we can't issue a command to clear the hardwarecache, and complain loudly with an xhci_warn() if this ever happens.This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correctassumptions about number of rings per endpoint.") early on in the XHCIdriver's life, when stream support was first added.It was then identified but not fixed nor made into a warning in commit674f8438c121 ("xhci: split handling halted endpoints into two steps"),which added a FIXME comment for the problem case (without materiallychanging the behavior as far as I can tell, though the new logic madethe problem more obvious).Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back somecached cancelled URBs."), it was acknowledged again.[Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cachedcancelled URBs.") was a targeted regression fix to the previously mentionedpatch. Users reported issues with usb stuck after unmounting/disconnectingUAS devices. This rolled back the TD clearing of multiple streams to itsoriginal state.]Apparently the commit author was aware of the problem (yet still choseto submit it): It was still mentioned as a FIXME, an xhci_dbg() wasadded to log the problem condition, and the remaining issue was mentionedin the commit description. The choice of making the log type xhci_dbg()for what is, at this point, a completely unhandled and known brokencondition is puzzling and unfortunate, as it guarantees that no actualusers would see the log in production, thereby making it nighundebuggable (indeed, even if you turn on DEBUG, the message doesn'treally hint at there being a problem at all).It took me *months* of random xHC crashes to finally find a reliablerepro and be able to do a deep dive debug session, which could all havebeen avoided had this unhandled, broken condition been actually reportedwith a warning, as it should have been as a bug intentionally left inunfixed (never mind that it shouldn't have been left in at all).> Another fix to solve clearing the caches of all stream rings with> cancelled TDs is needed, but not as urgent.3 years after that statement and 14 years after the original bug wasintroduced, I think it's finally time to fix it. And maybe next timelet's not leave bugs unfixed (that are actually worse than the originalbug), and let's actually get people to review kernel commits please.Fixes xHC crashes and IOMMU faults with UAS devices when handlingerrors/faults. Easiest repro is to use `hdparm` to mark an early sector(e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.At least in the case of JMicron controllers, the read errors end uphaving to cancel two TDs (for two queued requests to different streams)and the one that didn't get cleared properly ends up faulting the xHCentirely when it tries to access DMA pages that have since been unmapped,referred to by the stale TDs. This normally happens quickly (after twoor three loops). After this fix, I left the `cat` in a loop runningovernight and experienced no xHC failures, with all read errorsrecovered properly. Repro'd and tested on an Apple M1 Mac Mini(dwc3 host).On systems without an IOMMU, this bug would instead silently corruptfreed memory, making this a---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/dpaa2: Avoid explicit cpumask var allocation on stackFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumaskvariable on stack is not recommended since it can cause potential stackoverflow.Instead, kernel code should always use *cpumask_var API(s) to allocatecpumask var in config-neutral way, leaving allocation strategy toCONFIG_CPUMASK_OFFSTACK.Use *cpumask_var API(s) to address it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()Userspace provided string 's' could trivially have the length zero. Leftunchecked this will firstly result in an OOB read in the form`if (str[0 - 1] == '\n') followed closely by an OOB write in the form`str[0 - 1] = '\0'`.There is already a validating check to catch strings that are too long.Let's supply an additional check for invalid strings that are too short.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write errorEnsure index in rtl2830_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write errorEnsure index in rtl2832_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.[hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue in`cm_helper_translate_curve_to_degamma_hw_format` function. The issuecould occur when the index 'i' exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix ppp_async_encode() illegal accesssyzbot reported an issue in ppp_async_encode() [1]In this case, pppoe_sendmsg() is called with a zero size.Then ppp_async_encode() is called with an empty skb.BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: fix uninit-value use in udf_get_fileshortadCheck for overflow when computing alen in udf_current_aext to mitigatelater uninit-value use in udf_get_fileshortad KMSAN bug[1].After applying the patch reproducer did not trigger any issue[2].[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bnep: fix wild-memory-access in proto_unregisterThere's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAs bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()will cleanup all resource. Then when remove bnep module will callbnep_sock_cleanup() to cleanup sock's resource.To solve above issue just return bnep_sock_init()'s return value inbnep_exit().
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmode should keep reference to parentThe altmode device release refers to its parent device, but without keepinga reference to it.When registering the altmode, get a reference to the parent and put it inthe release function.Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issueslike this:[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)[ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)[ 46.612867] ==================================================================[ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129[ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48[ 46.614538][ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535[ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 46.616042] Workqueue: events kobject_delayed_cleanup[ 46.616446] Call Trace:[ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c[ 46.617112] ? typec_altmode_release+0x38/0x129[ 46.617470] print_report+0x14c/0x49e[ 46.617769] ? rcu_read_unlock_sched+0x56/0x69[ 46.618117] ? __virt_addr_valid+0x19a/0x1ab[ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d[ 46.618807] ? typec_altmode_release+0x38/0x129[ 46.619161] kasan_report+0x8d/0xb4[ 46.619447] ? typec_altmode_release+0x38/0x129[ 46.619809] ? process_scheduled_works+0x3cb/0x85f[ 46.620185] typec_altmode_release+0x38/0x129[ 46.620537] ? process_scheduled_works+0x3cb/0x85f[ 46.620907] device_release+0xaf/0xf2[ 46.621206] kobject_delayed_cleanup+0x13b/0x17a[ 46.621584] process_scheduled_works+0x4f6/0x85f[ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10[ 46.622353] ? hlock_class+0x31/0x9a[ 46.622647] ? lock_acquired+0x361/0x3c3[ 46.622956] ? move_linked_works+0x46/0x7d[ 46.623277] worker_thread+0x1ce/0x291[ 46.623582] ? __kthread_parkme+0xc8/0xdf[ 46.623900] ? __pfx_worker_thread+0x10/0x10[ 46.624236] kthread+0x17e/0x190[ 46.624501] ? kthread+0xfb/0x190[ 46.624756] ? __pfx_kthread+0x10/0x10[ 46.625015] ret_from_fork+0x20/0x40[ 46.625268] ? __pfx_kthread+0x10/0x10[ 46.625532] ret_from_fork_asm+0x1a/0x30[ 46.625805] [ 46.625953][ 46.626056] Allocated by task 678:[ 46.626287] kasan_save_stack+0x24/0x44[ 46.626555] kasan_save_track+0x14/0x2d[ 46.626811] __kasan_kmalloc+0x3f/0x4d[ 46.627049] __kmalloc_noprof+0x1bf/0x1f0[ 46.627362] typec_register_port+0x23/0x491[ 46.627698] cros_typec_probe+0x634/0xbb6[ 46.628026] platform_probe+0x47/0x8c[ 46.628311] really_probe+0x20a/0x47d[ 46.628605] device_driver_attach+0x39/0x72[ 46.628940] bind_store+0x87/0xd7[ 46.629213] kernfs_fop_write_iter+0x1aa/0x218[ 46.629574] vfs_write+0x1d6/0x29b[ 46.629856] ksys_write+0xcd/0x13b[ 46.630128] do_syscall_64+0xd4/0x139[ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 46.630820][ 46.630946] Freed by task 48:[ 46.631182] kasan_save_stack+0x24/0x44[ 46.631493] kasan_save_track+0x14/0x2d[ 46.631799] kasan_save_free_info+0x3f/0x4d[ 46.632144] __kasan_slab_free+0x37/0x45[ 46.632474]---truncated---
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds write in trie_get_next_key()trie_get_next_key() allocates a node stack with size trie->max_prefixlen,while it writes (trie->max_prefixlen + 1) nodes to the stack when it hasfull paths from the root to leaves. For example, consider a trie withmax_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with.prefixlen = 8 make 9 nodes be written on the node stack with size 8.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004[...][ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[...][ 57.331328] Call Trace:[ 57.331477] [...][ 57.333511] ? do_user_addr_fault+0x3e5/0x740[ 57.333778] ? exc_page_fault+0x70/0x170[ 57.334016] ? asm_exc_page_fault+0x2b/0x30[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0[ 57.335164] ocfs2_xa_set+0x704/0xcf0[ 57.335381] ? _raw_spin_unlock+0x1a/0x40[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20[ 57.335915] ? trace_preempt_on+0x1e/0x70[ 57.336153] ? start_this_handle+0x16c/0x500[ 57.336410] ? preempt_count_sub+0x50/0x80[ 57.336656] ? _raw_read_unlock+0x20/0x40[ 57.336906] ? start_this_handle+0x16c/0x500[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0[ 57.337706] ? ocfs2_start_trans+0x13d/0x290[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0[ 57.338207] ? dput+0x46/0x1c0[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30[ 57.338948] __vfs_removexattr+0x92/0xc0[ 57.339182] __vfs_removexattr_locked+0xd5/0x190[ 57.339456] ? preempt_count_sub+0x50/0x80[ 57.339705] vfs_removexattr+0x5f/0x100[...]Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->ocfs2_xa_value_truncate() with -ENOMEM.In this case the comment mentions that we can return 0 ifocfs2_xa_cleanup_value_truncate() is going to wipe the entryanyway. But the following 'rc' check is wrong and execution flow do'ocfs2_xa_remove_entry(loc);' twice:* 1st: in ocfs2_xa_cleanup_value_truncate();* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.Fix this by skipping the 2nd removal of the same entry and makingsyzkaller repro happy.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out of bounds reads when finding clock sourcesThe current USB-audio driver code doesn't check bLength of eachdescriptor at traversing for clock descriptors. That is, when adevice provides a bogus descriptor with a shorter bLength, the drivermight hit out-of-bounds reads.For addressing it, this patch adds sanity checks to the validatorfunctions for the clock descriptor traversal. When the descriptorlength is shorter than expected, it's skipped in the loop.For the clock source and clock multiplier descriptors, we can justcheck bLength against the sizeof() of each descriptor type.OTOH, the clock selector descriptor of UAC2 and UAC3 has an arrayof bNrInPins elements and two more fields at its tail, hence thosehave to be checked in addition to the sizeof() check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctlFix an issue detected by syzbot with KASAN:BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/core.c:416 [inline]BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0drivers/acpi/nfit/core.c:459The issue occurs in cmd_to_func when the call_pkg->nd_reserved2array is accessed without verifying that call_pkg points to a bufferthat is appropriately sized as a struct nd_cmd_pkg. This can leadto out-of-bounds access and undefined behavior if the buffer does nothave sufficient space.To address this, a check was added in acpi_nfit_ctl() to ensure thatbuf is not NULL and that buf_len is less than sizeof(*call_pkg)before accessing it. This ensures safe access to the members ofcall_pkg, including the nd_reserved2 array.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Prevent integer overflow issueIn the expression "cmd.wqe_size * cmd.wr_count", both variables are u32values that come from the user so the multiplication can lead to integerwrapping. Then we pass the result to uverbs_request_next_ptr() which alsocould potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"multiplication can also overflow on 32bit systems although it's fine on64bit systems.This patch does two things. First, I've re-arranged the condition inuverbs_request_next_ptr() so that the use controlled variable "len" is onone side of the comparison by itself without any math. Then I've modifiedall the callers to use size_mul() for the multiplications.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAXShifting 1 << 31 on a 32-bit int causes signed integer overflow, whichleads to undefined behavior. To prevent this, cast 1 to u32 beforeperforming the shift, ensuring well-defined behavior.This change explicitly avoids any potential overflow by ensuring thatthe shift occurs on an unsigned 32-bit integer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libtasn1 > 0-0 (version in image is 4.9-3.13.1).
-
Description: libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.81.1 (version in image is 2.9.4-46.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast racehuge_pmd_unshare() drops a reference on a page table that may havepreviously been shared across processes, potentially turning it into anormal page table used in another process in which unrelated VMAs canafterwards be installed.If this happens in the middle of a concurrent gup_fast(), gup_fast() couldend up walking the page tables of another process. While I don't see anyway in which that immediately leads to kernel memory corruption, it isreally weird and unexpected.Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),just like we do in khugepaged when removing page tables for a THPcollapse.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix error flow upon firmware failure for RQ destructionUpon RQ destruction if the firmware command fails which is thelast resource to be destroyed some SW resources were already cleanedregardless of the failure.Now properly rollback the object to its original state upon such failure.In order to avoid a use-after free in case someone tries to destroy theobject again, which results in the following kernel trace:refcount_t: underflow; use-after-free.WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : refcount_warn_saturate+0xf4/0x148lr : refcount_warn_saturate+0xf4/0x148sp : ffff80008b81b7e0x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37fx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fffx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix ktls panic with sockmap[ 2172.936997] ------------[ cut here ]------------[ 2172.936999] kernel BUG at lib/iov_iter.c:629!......[ 2172.944996] PKRU: 55555554[ 2172.945155] Call Trace:[ 2172.945299] [ 2172.945428] ? die+0x36/0x90[ 2172.945601] ? do_trap+0xdd/0x100[ 2172.945795] ? iov_iter_revert+0x178/0x180[ 2172.946031] ? iov_iter_revert+0x178/0x180[ 2172.946267] ? do_error_trap+0x7d/0x110[ 2172.946499] ? iov_iter_revert+0x178/0x180[ 2172.946736] ? exc_invalid_op+0x50/0x70[ 2172.946961] ? iov_iter_revert+0x178/0x180[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20[ 2172.947446] ? iov_iter_revert+0x178/0x180[ 2172.947683] ? iov_iter_revert+0x5c/0x180[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840[ 2172.948206] tls_sw_sendmsg+0x52/0x80[ 2172.948420] ? inet_sendmsg+0x1f/0x70[ 2172.948634] __sys_sendto+0x1cd/0x200[ 2172.948848] ? find_held_lock+0x2b/0x80[ 2172.949072] ? syscall_trace_enter+0x140/0x270[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170[ 2172.949595] ? find_held_lock+0x2b/0x80[ 2172.949817] ? syscall_trace_enter+0x140/0x270[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0[ 2172.951036] __x64_sys_sendto+0x24/0x30[ 2172.951382] do_syscall_64+0x90/0x170......After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,e.g., when the BPF program executes bpf_msg_push_data().If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,it will return -ENOSPC and attempt to roll back to the non-zero copylogic. However, during rollback, msg->msg_iter is reset, but sincemsg_pl->sg.size has been increased, subsequent executions will exceed theactual size of msg_iter.'''iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);'''The changes in this commit are based on the following considerations:1. When cork_bytes is set, rolling back to non-zero copy logic ispointless and can directly go to zero-copy logic.2. We can not calculate the correct number of bytes to revert msg_iter.Assume the original data is "abcdefgh" (8 bytes), and after 3 pushesby the BPF program, it becomes 11-byte data: "abc?de?fgh?".Then, we set cork_bytes to 6, which means the first 6 bytes have beenprocessed, and the remaining 5 bytes "?fgh?" will be cached until thelength meets the cork_bytes requirement.However, some data in "?fgh?" is not within 'sg->msg_iter'(but in msg_pl instead), especially the data "?" we pushed.So it doesn't seem as simple as just reverting through an offset ofmsg_iter.3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,the user-space send() doesn't return an error, and the returned length isthe same as the input length parameter, even if some data is cached.Additionally, I saw that the current non-zero-copy logic for handlingcorking is written as:'''line 1177else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end;'''So it's ok to just return 'copied' without error when a "cork" situationoccurs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gem: Acquire references on GEM handles for framebuffersA GEM handle can be released while the GEM buffer object is attachedto a DRM framebuffer. This leads to the release of the dma-buf backingthe buffer object, if any. [1] Trying to use the framebuffer in furthermode-setting operations leads to a segmentation fault. Most easilyhappens with driver that use shadow planes for vmap-ing the dma-bufduring a page flip. An example is shown below.[ 156.791968] ------------[ cut here ]------------[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430[...][ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430[ 157.043420] Call Trace:[ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710[ 157.065567] ? dma_buf_vmap+0x224/0x430[ 157.069446] ? __warn.cold+0x58/0xe4[ 157.073061] ? dma_buf_vmap+0x224/0x430[ 157.077111] ? report_bug+0x1dd/0x390[ 157.080842] ? handle_bug+0x5e/0xa0[ 157.084389] ? exc_invalid_op+0x14/0x50[ 157.088291] ? asm_exc_invalid_op+0x16/0x20[ 157.092548] ? dma_buf_vmap+0x224/0x430[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10[ 157.110697] drm_gem_shmem_vmap+0x74/0x710[ 157.114866] drm_gem_vmap+0xa9/0x1b0[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0[ 157.123086] drm_gem_fb_vmap+0xab/0x300[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10[ 157.133032] ? lockdep_init_map_type+0x19d/0x880[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40[...][ 157.346424] ---[ end trace 0000000000000000 ]---Acquiring GEM handles for the framebuffer's GEM buffer objects preventsthis from happening. The framebuffer's cleanup later puts the handlereferences.Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM objectinstance") triggers the segmentation fault easily by using the dma-buffield more widely. The underlying issue with reference counting hasbeen present before.v2:- acquire the handle instead of the BO (Christian)- fix comment style (Christian)- drop the Fixes tag (Christian)- rename err_ gotos- add missing Link tag
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Harden s32ton() against conversion to 0 bitsTesting by the syzbot fuzzer showed that the HID core gets ashift-out-of-bounds exception when it tries to convert a 32-bitquantity to a 0-bit quantity. Ideally this should never occur, butthere are buggy devices and some might have a report field with sizeset to zero; we shouldn't reject the report or the device just becauseof that.Instead, harden the s32ton() routine so that it returns a reasonableresult instead of crashing when it is called with the number of bitsset to 0 -- the same as what snto32() does.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pptp: ensure minimal skb length in pptp_xmit()Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb dataon ppp_sync_txmung") fixed ppp_sync_txmunge()We need a similar fix in pptp_xmit(), otherwise we mightread uninit data as reported by syzbot.BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Kill URBs before clearing tx status queueIn rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearingb_tx_status.queue. This change prevents callbacks from using already freedskb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOVBefore disabling SR-IOV via config space accesses to the parent PF,sriov_disable() first removes the PCI devices representing the VFs.Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")such removal operations are serialized against concurrent remove andrescan using the pci_rescan_remove_lock. No such locking was ever addedin sriov_disable() however. In particular when commit 18f9e9d150fc("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI deviceremoval into sriov_del_vfs() there was still no locking around thepci_iov_remove_virtfn() calls.On s390 the lack of serialization in sriov_disable() may cause doubleremove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2.This is because in addition to sriov_disable() removing the VFs, theplatform also generates hot-unplug events for the VFs. This being thereverse operation to the hotplug events generated by sriov_enable() andhandled via pdev->no_vf_scan. And while the event processing takespci_rescan_remove_lock and checks whether the struct pci_dev still exists,the lack of synchronization makes this checking racy.Other races may also be possible of course though given that this lack oflocking persisted so long observable races seem very rare. Even on s390 thelist corruption was only observed with certain devices since the platformevents are only triggered by config accesses after the removal, so as longas the removal finished synchronously they would not race. Either way thelocking is missing so fix this by adding it to the sriov_del_vfs() helper.Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()including for the error case where pci_stop_and_remove_bus_device() iscalled without the PCI rescan-remove lock being held. Even in the non-errorcase, adding new PCI devices and buses should be serialized via the PCIrescan-remove lock. Add the necessary locking.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAFThere is a KASAN: slab-use-after-free read in btusb_disconnect().Calling "usb_driver_release_interface(&btusb_driver, data->intf)" willfree the btusb data associated with the interface. The same data isthen used later in the function, hence the UAF.Fix by moving the accesses to btusb data to before the data is free'd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- net-tools > 0-0 (version in image is 1.60-765.5.4).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc > 0-0 (version in image is 2.22-114.31.1).
-
Description: In SQLite through 3.29.0, whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlite_stat1 sz field, aka a "severe division by zero in the query planner."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sqlite3-tcl > 0-0 (version in image is 3.39.3-9.26.1).
-
Description: The Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.5 and 1.19.x before 1.19.3 has a NULL pointer dereference in kdc/do_tgs_req.c via a FAST inner body that lacks a server field.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 < 1.16.3-46.12.1 (version in image is 1.12.5-40.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: Add validation for used lengthThis adds validation for used length (might comefrom an untrusted device) to avoid data corruptionor loss.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: fix a use-after-freeFix the following use-after-free complaint triggered by blktests nvme/004:BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix linkwatch use-after-free on disconnectusbnet uses the work usbnet_deferred_kevent() to perform tasks which maysleep. On disconnect, completion of the work was originally awaited in->ndo_stop(). But in 2003, that was moved to ->disconnect() by historiccommit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83cThe change was made because back then, the kernel's workqueueimplementation did not allow waiting for a single work. One had to waitfor completion of *all* work by calling flush_scheduled_work(), and thatcould deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutexheld in ->ndo_stop().The commit solved one problem but created another: It causes ause-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,ax88179_178a.c, ch9200.c and smsc75xx.c:* If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent().* usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}().* That in turn schedules the work linkwatch_event().Because usbnet_deferred_kevent() is awaited after unregister_netdev(),netif_carrier_{on,off}() may operate on an unregistered netdev andlinkwatch_event() may run after free_netdev(), causing a use-after-free.In 2010, usbnet was changed to only wait for a single instance ofusbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf("drivers/net: don't use flush_scheduled_work()").Unfortunately the commit neglected to move the wait back to->ndo_stop(). Rectify that omission at long last.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failedWhen the ops_init() interface is invoked to initialize the net, butops->init() fails, data is released. However, the ptr pointer innet->gen is invalid. In this case, when nfqnl_nf_hook_drop() is invokedto release the net, invalid address access occurs.The process is as follows:setup_net() ops_init() data = kzalloc(...) ---> alloc "data" net_assign_generic() ---> assign "date" to ptr in net->gen ... ops->init() ---> failed ... kfree(data); ---> ptr in net->gen is invalid ... ops_exit_list() ... nfqnl_nf_hook_drop() *q = nfnl_queue_pernet(net) ---> q is invalidThe following is the Call Trace information:BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280Read of size 8 at addr ffff88810396b240 by task ip/15855Call Trace:dump_stack_lvl+0x8e/0xd1print_report+0x155/0x454kasan_report+0xba/0x1f0nfqnl_nf_hook_drop+0x264/0x280nf_queue_nf_hook_drop+0x8b/0x1b0__nf_unregister_net_hook+0x1ae/0x5a0nf_unregister_net_hooks+0xde/0x130ops_exit_list+0xb0/0x170setup_net+0x7ac/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Allocated by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30__kasan_kmalloc+0xa1/0xb0__kmalloc+0x49/0xb0ops_init+0xe7/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Freed by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30kasan_save_free_info+0x2a/0x40____kasan_slab_free+0x155/0x1b0slab_free_freelist_hook+0x11b/0x220__kmem_cache_free+0xa4/0x360ops_init+0xb9/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- suse-module-tools < 12.13-3.11.1 (version in image is 12.11-3.8.1).
-
Description: Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A ReDoS issue was discovered in the Time component through 0.2.1 in Ruby through 3.2.1. The Time parser mishandles invalid URLs that have specific characters. It causes an increase in execution time for parsing strings to Time objects. The fixed versions are 0.1.1 and 0.2.2.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.6, tvOS 17, iOS 16.7 and iPadOS 16.7, macOS Monterey 12.7, watchOS 10, iOS 17 and iPadOS 17, macOS Sonoma 14. Processing web content may disclose sensitive information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxslt1 > 0-0 (version in image is 1.1.28-17.15.1).
-
Description: A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: libxml2 through 2.11.5 has a use-after-free that can only occur after a certain memory allocation fails. This occurs in xmlUnlinkNode in tree.c. NOTE: the vendor's position is "I don't think these issues are critical enough to warrant a CVE ID ... because an attacker typically can't control when memory allocations fail."
Packages affected:
- libxml2-2 < 2.9.4-46.68.2 (version in image is 2.9.4-46.65.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- openssh < 7.2p2-81.12.1 (version in image is 7.2p2-81.4.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential OOBs in smb2_parse_contexts()Validate offsets and lengths before dereferencing create contexts insmb2_parse_contexts().This fixes following oops when accessing invalid create contexts fromserver: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU lengthIf the host sends an H2CData command with an invalid DATAL,the kernel may crash in nvmet_tcp_build_pdu_iovec().Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000000lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110Fix the bug by raising a fatal error if DATAL isn't coherentwith the packet size.Also, the PDU length should never exceed the MAXH2CDATA parameter whichhas been communicated to the host in nvmet_tcp_handle_icreq().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Do not update file length for failed writes to inline filesWhen write to inline file fails (or happens only partly), we stillupdated length of inline data as if the whole write succeeded. Fix theupdate of length of inline data to happen only if the write succeeds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firewire: net: fix use after free in fwnet_finish_incoming_packet()The netif_rx() function frees the skb so we can't dereference it tosave the skb->len.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: do not update mtu if msg_max is too small in mtu negotiationWhen doing link mtu negotiation, a malicious peer may send Activate msgwith a very small mtu, e.g. 4 in Shuang's testing, without checking forthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), thenn->links[bearer_id].mtu is set to 4294967228, which is a overflow of'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4!And with tipc_link_entry.mtu 4294967228, a huge skb was allocated innamed_distribute(), and when purging it in tipc_link_xmit(), a crashwas even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),and not updating mtu if it is too small.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: reject auth/assoc to AP with our addressIf the AP uses our own address as its MLD address or BSSID, thenclearly something's wrong. Reject such connections so we don'ttry and fail later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix out-of-bounds access in ipv6_find_tlv()optlen is fetched without checking whether there is more than one byte to parse.It can lead to out-of-bounds access.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hexApparently the hex passphrase mechanism does not work on newerchips/firmware (e.g. BCM4387). It seems there was a simple way ofpassing it in binary all along, so use that and avoid the hexification.OpenBSD has been doing it like this from the beginning, so this shouldwork on all chips.Also clear the structure before setting the PMK. This was leakinguninitialized stack contents to the device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: NSS was susceptible to a timing side-channel attack when performing RSA decryption. This attack could potentially allow an attacker to recover the private data. This vulnerability affects Firefox < 124, Firefox ESR < 115.9, and Thunderbird < 115.9.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- mozilla-nss-certs < 3.101.1-58.118.1 (version in image is 3.90-58.104.1).
-
Description: A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- rsync < 3.1.3-3.22.1 (version in image is 3.1.3-3.14.1).
-
Description: A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- rsync < 3.1.3-3.22.1 (version in image is 3.1.3-3.14.1).
-
Description: When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.86.2 (version in image is 8.0.1-11.74.1).
-
Description: A vulnerability was identified in the kjd/idna library, specifically within the `idna.encode()` function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-idna < 2.5-3.13.1 (version in image is 2.5-3.10.2).
-
Description: In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 < 1.16.3-46.15.1 (version in image is 1.12.5-40.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:skmsg: Skip zero length skb in sk_msg_recvmsgWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarchplatform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...]This crash happens every time when running sockmap_skb_verdict_shutdownsubtest in sockmap_basic.This crash is because a NULL pointer is passed to page_address() in thesk_msg_recvmsg(). Due to the different implementations depending on thearchitecture, page_address(NULL) will trigger a panic on Loongarchplatform but not on x86 platform. So this bug was hidden on x86 platformfor a while, but now it is exposed on Loongarch platform. The root causeis that a zero length skb (skb->len == 0) was put on the queue.This zero length skb is a TCP FIN packet, which was sent by shutdown(),invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR);In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and nopage is put to this sge (see sg_set_page in sg_set_page), but this emptysge is queued into ingress_msg list.And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got bysg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes itto kmap_local_page() and to page_address(), then kernel panics.To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),if copy is zero, that means it's a zero length skb, skip invokingcopy_page_to_iter(). We are using the EFAULT return triggered bycopy_page_to_iter to check for is_fin in tcp_bpf.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: add missing verification for short frameThe cited commit missed to check against the validity of the frame lengthin the tun_xdp_one() path, which could cause a corrupted skb to be sentdownstack. Even before the skb is transmitted, thetun_xdp_one-->eth_type_trans() may access the Ethernet header although itcan be less than ETH_HLEN. Once transmitted, this could either causeout-of-bound access beyond the actual length, or confuse the underlayerwith incorrect or inconsistent header length in the skb metadata.In the alternative path, tun_get_user() already prohibits short frame whichhas the length less than Ethernet header size from being transmitted forIFF_TAP.This is to drop any frame shorter than the Ethernet header size just likehow tun_get_user() does.CVE: CVE-2024-41091
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fix kernel crash if commands allocation failsIf the commands allocation fails in nvmet_tcp_alloc_cmds()the kernel crashes in nvmet_tcp_release_queue_work() because ofa NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008Fix the bug by setting queue->nr_cmds to zero in casenvmet_tcp_alloc_cmd() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dpaa: Pad packets to ETH_ZLENWhen sending packets under 60 bytes, up to three bytes of the bufferfollowing the data may be leaked. Avoid this by extending all packets toETH_ZLEN, ensuring nothing is leaked in the padding. This bug can bereproduced by running $ ping -s 11 destination
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sendinggarbage on the four reserved tcp bits (th->res1)Use skb_put_zero() to clear the whole TCP header,as done in nf_reject_ip_tcphdr_put()BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: properly validate chunk size in sctp_sf_ootb()A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: addsize validation when walking chunks") is also required in sctp_sf_ootb()to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.92.1 (version in image is 8.0.1-11.74.1).
-
Description: A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
-
Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools < 2.48.2-12.52.1 (version in image is 2.48.2-12.34.1).
-
Description: User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
-
Description: In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 > 0-0 (version in image is 1.12.5-40.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: prevent A-MSDU attacks in mesh networksThis patch is a mitigation to prevent the A-MSDU spoofing vulnerabilityfor mesh networks. The initial update to the IEEE 802.11 standard, inresponse to the FragAttacks, missed this case (CVE-2025-27558). It canbe considered a variant of CVE-2020-24588 but for mesh networks.This patch tries to detect if a standard MSDU was turned into an A-MSDUby an adversary. This is done by parsing a received A-MSDU as a standardMSDU, calculating the length of the Mesh Control header, and seeing ifthe 6 bytes after this header equal the start of an rfc1042 header. Ifequal, this is a strong indication of an ongoing attack attempt.This defense was tested with mac80211_hwsim against a mesh network thatuses an empty Mesh Address Extension field, i.e., when four addressesare used, and when using a 12-byte Mesh Address Extension field, i.e.,when six addresses are used. Functionality of normal MSDUs and A-MSDUswas also tested, and confirmed working, when using both an empty and12-byte Mesh Address Extension field.It was also tested with mac80211_hwsim that A-MSDU attacks in non-meshnetworks keep being detected and prevented.Note that the vulnerability being patched, and the defense beingimplemented, was also discussed in the following paper and in thefollowing IEEE 802.11 presentation:https://papers.mathyvanhoef.com/wisec2025.pdfhttps://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmscape: Add conditional IBPB mitigationVMSCAPE is a vulnerability that exploits insufficient branch predictorisolation between a guest and a userspace hypervisor (like QEMU). Existingmitigations already protect kernel/KVM from a malicious guest. Userspacecan additionally be protected by flushing the branch predictors after aVMexit.Since it is the userspace that consumes the poisoned branch predictors,conditionally issue an IBPB after a VMexit and before returning touserspace. Workloads that frequently switch between hypervisor anduserspace will incur the most overhead from the new IBPB.This new IBPB is not integrated with the existing IBPB sites. Forinstance, a task can use the existing speculation control prctl() toget an IBPB at context switch time. With this implementation, theIBPB is doubled up: one at context switch and another before runninguserspace.The intent is to integrate and optimize these cases post-embargo.[ dhansen: elaborate on suboptimal IBPB solution ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, an unsafe deserialization and validation of printer attributes causes null dereference in the libcups library. This is a remote DoS vulnerability available in local subnet in default configurations. It can cause the cups & cups-browsed to crash, on all the machines in local network who are listening for printers (so by default for all regular linux machines). On systems where the vulnerability CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was not fixed, and the firewall on the machine does not reject incoming communication to IPP port, and the machine is set to be available to public internet, attack vector "Network" is possible. The current versions of CUPS and cups-browsed projects have the attack vector "Adjacent" in their default configurations. Version 2.4.13 contains a patch for CVE-2025-58364.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- cups-libs < 1.7.5-20.54.1 (version in image is 1.7.5-20.46.1).
-
Description: Ruby WEBrick read_header HTTP Request Smuggling Vulnerability. This vulnerability allows remote attackers to smuggle arbitrary HTTP requests on affected installations of Ruby WEBrick. This issue is exploitable when the product is deployed behind an HTTP proxy that fulfills specific conditions.The specific flaw exists within the read_headers method. The issue results from the inconsistent parsing of terminators of HTTP headers. An attacker can leverage this vulnerability to smuggle arbitrary HTTP requests. Was ZDI-CAN-21876.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.18.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctlyThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have aLS_NLA_TYPE_DGID attribute, it is invalid if it does not.Use the nl parsing logic properly and call nla_parse_deprecated() to fillthe nlattrs array and then directly index that array to get the data forthe DGID. Just fail if it is NULL.Remove the for loop searching for the nla, and squash the validation andparsing into one function.Fixes an uninitialized read from the stack triggered by userspace if itdoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVEquery. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: There is a defect in the CPython "tarfile" module affecting the "TarFile" extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. This vulnerability can be mitigated by including the following patch after importing the "tarfile" module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: The email module, specifically the "BytesGenerator" class, didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. This is only applicable if using "LiteralHeader" writing headers that don't respect email folding rules, the new behavior will reject the incorrectly folded headers in "BytesGenerator".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: Fix a potential use after freeFree the adap structure only after we are done using it.This patch just moves the put_device() down a bit to avoid theuse after free.[wsa: added comment to the code, added Fixes tag]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: Improper access control in BlueZ may allow an authenticated user to potentially enable information disclosure via adjacent access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix use-after-free error during resetCleans the next descriptor to watch (next_to_watch) when cleaning theTX ring.Failure to do so can cause invalid memory accesses. If igb_poll() runswhile the controller is reset this can lead to the driver try to freea skb that was already freed.(The crash is harder to reproduce with the igb driver, but the samepotential problem exists as the code is identical to igc)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igc: Fix use-after-free error during resetCleans the next descriptor to watch (next_to_watch) when cleaning theTX ring.Failure to do so can cause invalid memory accesses. If igc_poll() runswhile the controller is being reset this can lead to the driver try tofree a skb that was already freed.Log message: [ 101.525242] refcount_t: underflow; use-after-free. [ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0 [ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E) rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E) soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E) iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E) soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E) [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E) e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E) usbcore(E) drm(E) button(E) video(E) [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe [ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017 [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0 [ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48 44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3 [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286 [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001 [ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50 [ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00 [ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40 [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000 [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0 [ 101.525343] Call Trace: [ 101.525346] sock_wfree+0x9c/0xa0 [ 101.525353] unix_destruct_scm+0x7b/0xa0 [ 101.525358] skb_release_head_state+0x40/0x90 [ 101.525362] skb_release_all+0xe/0x30 [ 101.525364] napi_consume_skb+0x57/0x160 [ 101.525367] igc_poll+0xb7/0xc80 [igc] [ 101.525376] ? sched_clock+0x5/0x10 [ 101.525381] ? sched_clock_cpu+0xe/0x100 [ 101.525385] net_rx_action+0x14c/0x410 [ 101.525388] __do_softirq+0xe9/0x2f4 [ 101.525391] __local_bh_enable_ip+0xe3/0x110 [ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0 [ 101.525398] irq_forced_thread_fn+0x6a/0x80 [ 101.525401] irq_thread+0xe8/0x180 [ 101.525403] ? wake_threads_waitq+0x30/0x30 [ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0 [ 101.525408] kthread+0x183/0x1a0 [ 101.525412] ? kthread_park+0x80/0x80 [ 101.525415] ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:watchdog: Fix possible use-after-free by calling del_timer_sync()This driver's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: nicstar: Fix possible use-after-free in nicstar_cleanup()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: iphase: fix possible use-after-free in ia_module_exit()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pdKASAN reports a use-after-free report when doing fuzz test:[693354.104835] ==================================================================[693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160[693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338[693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147[693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018[693354.105612] Call Trace:[693354.105621] dump_stack+0xf1/0x19b[693354.105626] ? show_regs_print_info+0x5/0x5[693354.105634] ? printk+0x9c/0xc3[693354.105638] ? cpumask_weight+0x1f/0x1f[693354.105648] print_address_description+0x70/0x360[693354.105654] kasan_report+0x1b2/0x330[693354.105659] ? bfq_io_set_weight_legacy+0xd3/0x160[693354.105665] ? bfq_io_set_weight_legacy+0xd3/0x160[693354.105670] bfq_io_set_weight_legacy+0xd3/0x160[693354.105675] ? bfq_cpd_init+0x20/0x20[693354.105683] cgroup_file_write+0x3aa/0x510[693354.105693] ? ___slab_alloc+0x507/0x540[693354.105698] ? cgroup_file_poll+0x60/0x60[693354.105702] ? 0xffffffff89600000[693354.105708] ? usercopy_abort+0x90/0x90[693354.105716] ? mutex_lock+0xef/0x180[693354.105726] kernfs_fop_write+0x1ab/0x280[693354.105732] ? cgroup_file_poll+0x60/0x60[693354.105738] vfs_write+0xe7/0x230[693354.105744] ksys_write+0xb0/0x140[693354.105749] ? __ia32_sys_read+0x50/0x50[693354.105760] do_syscall_64+0x112/0x370[693354.105766] ? syscall_return_slowpath+0x260/0x260[693354.105772] ? do_page_fault+0x9b/0x270[693354.105779] ? prepare_exit_to_usermode+0xf9/0x1a0[693354.105784] ? enter_from_user_mode+0x30/0x30[693354.105793] entry_SYSCALL_64_after_hwframe+0x65/0xca[693354.105875] Allocated by task 1453337:[693354.106001] kasan_kmalloc+0xa0/0xd0[693354.106006] kmem_cache_alloc_node_trace+0x108/0x220[693354.106010] bfq_pd_alloc+0x96/0x120[693354.106015] blkcg_activate_policy+0x1b7/0x2b0[693354.106020] bfq_create_group_hierarchy+0x1e/0x80[693354.106026] bfq_init_queue+0x678/0x8c0[693354.106031] blk_mq_init_sched+0x1f8/0x460[693354.106037] elevator_switch_mq+0xe1/0x240[693354.106041] elevator_switch+0x25/0x40[693354.106045] elv_iosched_store+0x1a1/0x230[693354.106049] queue_attr_store+0x78/0xb0[693354.106053] kernfs_fop_write+0x1ab/0x280[693354.106056] vfs_write+0xe7/0x230[693354.106060] ksys_write+0xb0/0x140[693354.106064] do_syscall_64+0x112/0x370[693354.106069] entry_SYSCALL_64_after_hwframe+0x65/0xca[693354.106114] Freed by task 1453336:[693354.106225] __kasan_slab_free+0x130/0x180[693354.106229] kfree+0x90/0x1b0[693354.106233] blkcg_deactivate_policy+0x12c/0x220[693354.106238] bfq_exit_queue+0xf5/0x110[693354.106241] blk_mq_exit_sched+0x104/0x130[693354.106245] __elevator_exit+0x45/0x60[693354.106249] elevator_switch_mq+0xd6/0x240[693354.106253] elevator_switch+0x25/0x40[693354.106257] elv_iosched_store+0x1a1/0x230[693354.106261] queue_attr_store+0x78/0xb0[693354.106264] kernfs_fop_write+0x1ab/0x280[693354.106268] vfs_write+0xe7/0x230[693354.106271] ksys_write+0xb0/0x140[693354.106275] do_syscall_64+0x112/0x370[693354.106280] entry_SYSCALL_64_after_hwframe+0x65/0xca[693354.106329] The buggy address belongs to the object at ffff888be0a35580 which belongs to the cache kmalloc-1k of size 1024[693354.106736] The buggy address is located 228 bytes inside of 1024-byte region [ffff888be0a35580, ffff888be0a35980)[693354.107114] The buggy address belongs to the page:[693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0[693354.107606] flags: 0x17ffffc0008100(slab|head)[693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080[693354.108020] r---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211: fix use-after-free in CCMP/GCMP RXWhen PN checking is done in mac80211, for fragmentation we needto copy the PN to the RX struct so we can later use it to do acomparison, since commit bf30ca922a0c ("mac80211: check defragPN against current frame").Unfortunately, in that commit I used the 'hdr' variable withoutit being necessarily valid, so use-after-free could occur if itwas necessary to reallocate (parts of) the frame.Fix this by reloading the variable after the code that resultsin the reallocations, if any.This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctlHulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock heldby ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can beconcurrent.ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.ubi_detach is bug-free because it uses reference counting to preventconcurrency. However, uif_init and uif_close in ubi_attach may race withubi_cdev_ioctl.uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_delAnd uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double freeThe cause of this problem is that commit 714fb87e8bc0 make device"available" before it becomes accessible via sysfs. Therefore, weroll back the modification. We will fix the race condition betweenubi device creation and udev by removing ubi_get_device invol_attribute_show and dev_attribute_show.This avoids accessinguninitialized ubi_devices[ubi_num].ubi_get_device is used to prevent devices from being deleted duringsysfs execution. However, now kernfs ensures that devices will notbe deleted before all reference counting are released.The key process is shown in the following stack.device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix possible use-after-free in transport error_recovery workWhile nvme_tcp_submit_async_event_work is checking the ctrl and queuestate before preparing the AER command and scheduling io_work, in orderto fully prevent a race where this check is not reliable the errorrecovery work must flush async_event_work before continuing to destroythe admin queue after setting the ctrl state to RESETTING such thatthere is no race .submit_async_event and the error recovery handleritself changing the ctrl state.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix a possible use-after-free in controller reset during loadUnlike .queue_rq, in .submit_async_event drivers may not check the ctrlreadiness for AER submission. This may lead to a use-after-freecondition that was observed with nvme-tcp.The race condition may happen in the following scenario:1. driver executes its reset_ctrl_work2. -> nvme_stop_ctrl - flushes ctrl async_event_work3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling4. teardown admin queue (which releases the queue socket)5. AEN processed, submits another AER, calling the driver to submit6. driver attempts to send the cmd==> use-after-freeIn order to fix that, add ctrl state check to validate the ctrlis actually able to accept the AER submission.This addresses the above race in controller resets because the driverduring teardown should:1. change ctrl state to RESETTING2. flush async_event_work (as well as other async work elements)So after 1,2, any other AER command will find thectrl state to be RESETTING and bail out without submitting the AER.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix double free race when mount fails in cifs_get_root()When cifs_get_root() fails during cifs_smb3_do_mount() we calldeactivate_locked_super() which eventually will call delayed_free() whichwill free the context.In this situation we should not proceed to enter the out: section incifs_smb3_do_mount() and free the same resources a second time.[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019[Thu Feb 10 12:59:06 2022] Call Trace:[Thu Feb 10 12:59:06 2022] [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78[Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60[Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60[Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0[Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60[Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0[Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0[Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20[Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140[Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10[Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b[Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150[Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30[Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0...[Thu Feb 10 12:59:07 2022] Freed by task 58179:[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50[Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30[Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40[Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170[Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20[Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0[Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs][Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs][Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae[Thu Feb 10 12:59:07 2022] Last potentially related work creation:[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50[Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0[Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10[Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0[Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs][Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs][Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs][Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs][Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: add flush_workqueue to prevent uafOur detector found a concurrent use-after-free bug when detaching anNCI device. The main reason for this bug is the unexpected schedulingbetween the used delayed mechanism (timer and workqueue).The race can be demonstrated below:Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work)nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] |... | Workernci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2]In short, the cleanup routine thought that the cmd_timer has alreadybeen detached by [1] but the mod_timer can re-attach the timer [2], evenit is already released [3], resulting in UAF.This UAF is easy to trigger, crash trace by POC is like below[ 66.703713] ==================================================================[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33[ 66.703974][ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work[ 66.703974] Call Trace:[ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d[ 66.703974] print_report.cold+0x5e/0x5db[ 66.703974] ? enqueue_timer+0x448/0x490[ 66.703974] kasan_report+0xbe/0x1c0[ 66.703974] ? enqueue_timer+0x448/0x490[ 66.703974] enqueue_timer+0x448/0x490[ 66.703974] __mod_timer+0x5e6/0xb80[ 66.703974] ? mark_held_locks+0x9e/0xe0[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410[ 66.703974] ? queue_work_on+0x61/0x80[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130[ 66.703974] process_one_work+0x8bb/0x1510[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230[ 66.703974] ? rwlock_bug.part.0+0x90/0x90[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50[ 66.703974] worker_thread+0x575/0x1190[ 66.703974] ? process_one_work+0x1510/0x1510[ 66.703974] kthread+0x2a0/0x340[ 66.703974] ? kthread_complete_and_exit+0x20/0x20[ 66.703974] ret_from_fork+0x22/0x30[ 66.703974] [ 66.703974][ 66.703974] Allocated by task 267:[ 66.703974] kasan_save_stack+0x1e/0x40[ 66.703974] __kasan_kmalloc+0x81/0xa0[ 66.703974] nci_allocate_device+0xd3/0x390[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0[ 66.703974] tty_ioctl+0x764/0x1310[ 66.703974] __x64_sys_ioctl+0x122/0x190[ 66.703974] do_syscall_64+0x3b/0x90[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 66.703974][ 66.703974] Freed by task 406:[ 66.703974] kasan_save_stack+0x1e/0x40[ 66.703974] kasan_set_track+0x21/0x30[ 66.703974] kasan_set_free_info+0x20/0x30[ 66.703974] __kasan_slab_free+0x108/0x170[ 66.703974] kfree+0xb0/0x330[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0[ 66.703974] nci_uart_tty_close+0xdf/0x180[ 66.703974] tty_ldisc_kill+0x73/0x110[ 66.703974] tty_ldisc_hangup+0x281/0x5b0[ 66.703974] __tty_hangup.part.0+0x431/0x890[ 66.703974] tty_release+0x3a8/0xc80[ 66.703974] __fput+0x1f0/0x8c0[ 66.703974] task_work_run+0xc9/0x170[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0[ 66.703974] syscall_exit_to_user_mode+0x19/0x50[ 66.703974] do_syscall_64+0x48/0x90[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Implement ref count for SRBThe timeout handler and the done function are racing. Whenqla2x00_async_iocb_timeout() starts to run it can be preempted by thenormal response path (via the firmware?). qla24xx_async_gpsc_sp_done()releases the SRB unconditionally. When scheduling back toqla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freedsp->qpair pointer: qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]Obvious solution to this is to introduce a reference counter. One referenceis taken for the normal code path (the 'good' case) and one for the timeoutpath. As we always race between the normal good case and the timeout/aborthandler we need to serialize it. Also we cannot assume any order betweenthe handlers. Since this is slow path we can use proper synchronization vialocks.When we are able to cancel a timer (del_timer returns 1) we know therecan't be any error handling in progress because the timeout handler hasn'texpired yet, thus we can safely decrement the refcounter by one.If we are not able to cancel the timer, we know an abort handler isrunning. We have to make sure we call sp->done() in the abort handlersbefore calling kref_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user inputMalformed user input to debugfs results in buffer overflow crashes. Adaptinput string lengths to fit within internal buffers, leaving space for NULLterminators.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix null-ptr-deref in ext4_write_infoI caught a null-ptr-deref bug as follows:==================================================================KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339RIP: 0010:ext4_write_info+0x53/0x1b0[...]Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ==================================================================Above issue may happen as follows:-------------------------------------exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereferenceTo solve this problem, we use ext4_journal_start_sb directlyto avoid s_root being used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()When executing SMP task failed, the smp_execute_task_sg() calls del_timer()to delete "slow_task->timer". However, if the timer handlersas_task_internal_timedout() is running, the del_timer() insmp_execute_task_sg() will not stop it and a UAF will happen. The processis shown below: (thread 1) | (thread 2)smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USEFix by calling del_timer_sync() in smp_execute_task_sg(), which makes surethe timer handler have finished before the "task->slow_task" isdeallocated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: Fix UAF in destroy()Dm_cache also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in destroy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Use different devices for resource allocation and DT lookupFollowing by the below discussion, there's the potential UAF issuebetween regulator and mfd.https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/From the analysis of YingliangCPU A |CPU Bmt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data()i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register()It's common to use mfd core to create child device for the regulator.In order to do the DT lookup for init data, the child that registeredthe regulator would pass its parent as the parameter. And this causesinit data resource allocated to its parent, not itself. The issue happenwhen parent device is going to release and regulator core is still doingsome operation of init data constraint for the regulator of child device.To fix it, this patch expand 'regulator_register' API to use thedifferent devices for init data allocation and DT lookup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.183.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix RPC client cleaned up the freed pipefs dentriesRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()workqueue,which takes care about pipefs superblock locking.In some special scenarios, when kernel frees the pipefs sb of thecurrent client and immediately alloctes a new pipefs sb,rpc_remove_pipedir function would misjudge the existence of pipefssb which is not the one it used to hold. As a result,the rpc_remove_pipedir would clean the released freed pipefs dentries.To fix this issue, rpc_remove_pipedir should check whether thecurrent pipefs sb is consistent with the original pipefs sb.This error can be catched by KASAN:=========================================================[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503[ 250.500549] Workqueue: events rpc_free_client_work[ 250.501001] Call Trace:[ 250.502880] kasan_report+0xb6/0xf0[ 250.503209] ? dget_parent+0x195/0x200[ 250.503561] dget_parent+0x195/0x200[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90[ 250.504781] rpc_remove_client_dir+0xf5/0x150[ 250.505195] rpc_free_client_work+0xe4/0x230[ 250.505598] process_one_work+0x8ee/0x13b0...[ 22.039056] Allocated by task 244:[ 22.039390] kasan_save_stack+0x22/0x50[ 22.039758] kasan_set_track+0x25/0x30[ 22.040109] __kasan_slab_alloc+0x59/0x70[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240[ 22.040889] __d_alloc+0x31/0x8e0[ 22.041207] d_alloc+0x44/0x1f0[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110[ 22.042459] rpc_create_client_dir+0x34/0x150[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0[ 22.043284] rpc_client_register+0x136/0x4e0[ 22.043689] rpc_new_client+0x911/0x1020[ 22.044057] rpc_create_xprt+0xcb/0x370[ 22.044417] rpc_create+0x36b/0x6c0...[ 22.049524] Freed by task 0:[ 22.049803] kasan_save_stack+0x22/0x50[ 22.050165] kasan_set_track+0x25/0x30[ 22.050520] kasan_save_free_info+0x2b/0x50[ 22.050921] __kasan_slab_free+0x10e/0x1a0[ 22.051306] kmem_cache_free+0xa5/0x390[ 22.051667] rcu_core+0x62c/0x1930[ 22.051995] __do_softirq+0x165/0x52a[ 22.052347][ 22.052503] Last potentially related work creation:[ 22.052952] kasan_save_stack+0x22/0x50[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0[ 22.054209] dentry_free+0xb2/0x140[ 22.054540] __dentry_kill+0x3be/0x540[ 22.054900] shrink_dentry_list+0x199/0x510[ 22.055293] shrink_dcache_parent+0x190/0x240[ 22.055703] do_one_tree+0x11/0x40[ 22.056028] shrink_dcache_for_umount+0x61/0x140[ 22.056461] generic_shutdown_super+0x70/0x590[ 22.056879] kill_anon_super+0x3a/0x60[ 22.057234] rpc_kill_sb+0x121/0x200
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix i_disksize exceeding i_size problem in paritally written caseIt is possible for i_disksize can exceed i_size, triggering a warning.generic_perform_write copied = iov_iter_copy_from_user_atomic(len) // copied < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + copied; | WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize | generic_write_end | copied = block_write_end(copied, len) // copied = 0 | if (unlikely(copied < len)) | if (!PageUptodate(page)) | copied = 0; | if (pos + copied > inode->i_size) // return false if (unlikely(copied == 0)) goto again; if (unlikely(iov_iter_fault_in_readable(i, bytes))) { status = -EFAULT; break; }We get i_disksize greater than i_size here, which could trigger WARNINGcheck 'i_size_read(inode) < EXT4_I(inode)->i_disksize' while doing dio:ext4_dio_write_iter iomap_dio_rw __iomap_dio_rw // return err, length is not aligned to 512 ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319 CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2 RIP: 0010:ext4_file_write_iter+0xbc7 Call Trace: vfs_write+0x3b1 ksys_write+0x77 do_syscall_64+0x39Fix it by updating 'copied' value before updating i_disksize just likeext4_write_inline_data_end() does.A reproducer can be found in the buganizer link below.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware writeDuring the sysfs firmware write process, a use-after-free read warning islogged from the lpfc_wr_object() routine: BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe driver accessed wr_object pointer data, which was initialized intomailbox payload memory, after the mailbox object was released back to themailbox pool.Fix by moving the mailbox free calls to the end of the routine ensuringthat we don't reference internal mailbox memory after release.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add bounds checking in get_max_inline_xattr_value_size()Normally the extended attributes in the inode body would have beenchecked when the inode is first opened, but if someone is writing tothe block device while the file system is mounted, it's possible forthe inode table to get corrupted. Add bounds checking to avoidreading beyond the end of allocated memory if this happens.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Sync IRQ works before buffer destructionIf something was written to the buffer just before destruction,it may be possible (maybe not in a real system, but it didhappen in ARCH=um with time-travel) to destroy the ringbufferbefore the IRQ work ran, leading this KASAN report (or a crashwithout KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00)Add the appropriate irq_work_sync() so the work finishes beforethe buffers are destroyed.Prior to the commit in the Fixes tag below, there was only asingle global IRQ work, so this issue didn't exist.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpcap1 < 1.8.1-10.6.1 (version in image is 1.8.1-10.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix uaf in pvr2_context_set_notify[Syzbot reported]BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Workqueue: usb_hub_wq hub_eventCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272Freed by task 906:kasan_save_stack+0x33/0x50 mm/kasan/common.c:47kasan_save_track+0x14/0x30 mm/kasan/common.c:68kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640poison_slab_object mm/kasan/common.c:241 [inline]__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257kasan_slab_free include/linux/kasan.h:184 [inline]slab_free_hook mm/slub.c:2121 [inline]slab_free mm/slub.c:4299 [inline]kfree+0x105/0x340 mm/slub.c:4409pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158[Analyze]Task A set disconnect_flag = !0, which resulted in Task B's condition being metand releasing mp, leading to this issue.[Fix]Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()to avoid this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport errorWhen ncm function is working and then stop usb0 interface for link down,eth_stop() is called. At this piont, accidentally if usb transport errorshould happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.After that, ncm_disable() is called to disable for ncm unbindbut gether_disconnect() is never called since 'in_ep' is not enabled.As the result, ncm object is released in ncm unbindbut 'dev->port_usb' associated to 'ncm->port' is not NULL.And when ncm bind again to recover netdev, ncm object is reallocatedbut usb0 interface is already associated to previous released ncm object.Therefore, once usb0 interface is up and eth_start_xmit() is called,released ncm object is dereferrenced and it might cause use-after-free memory.[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014fThis patch addresses the issue by checking if 'ncm->netdev' is not NULL atncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnectrather than check 'ncm->port.in_ep->enabled' since it might not be enabledbut the gether connection might be established.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().It looks up `stt` from tablefd, but then continues to use it after doingfdput() on the returned fd. After the fdput() the tablefd is free to beclosed by another thread. The close calls kvm_spapr_tce_release() andthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.Although there are calls to rcu_read_lock() inkvm_spapr_tce_attach_iommu_group() they are not sufficient to preventthe UAF, because `stt` is used outside the locked regions.With an artifcial delay after the fdput() and a userspace program whichtriggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14Fix it by delaying the fdput() until `stt` is no longer in use, whichis effectively the entire function. To keep the patch minimal add a callto fdput() at each of the existing return paths. Future work can convertthe function to goto or __cleanup style cleanup.With the fix in place the test case no longer triggers the UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: avoid double free special payloadIf a discard request needs to be retried, and that retry may fail beforea new special payload is added, a double free will result. Clear theRQF_SPECIAL_LOAD when the request is cleaned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dev/parport: fix the array out-of-bounds riskFixed array out-of-bounds issues caused by sprintfby replacing it with snprintf for safer data copying,ensuring the destination buffer is not overflowed.Below is the stack trace I encountered during the actual issue:[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport][ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYunPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: vhci-hcd: Do not drop references before new references are gainedAt a few places the driver carries stale pointersto references that can still be used. Make sure that does not happen.This strictly speaking closes ZDI-CAN-22273, though there may besimilar races in the driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: xc2028: avoid use-after-free in load_firmware_cb()syzkaller reported use-after-free in load_firmware_cb() [1].The reason is because the module allocated a struct tuner in tuner_probe(),and then the module initialization failed, the struct tuner was released.A worker which created during module initialization accesses this structtuner later, it caused use-after-free.The process is as follows:task-6504 worker_threadtuner_probe <= alloc dvb_frontend [2]...request_firmware_nowait <= create a worker...tuner_remove <= free dvb_frontend... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freedTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it isnull, report a warning and just return.[1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aacraid: Fix double-free on probe failureaac_probe_one() calls hardware-specific init functions through theaac_driver_ident::init pointer, all of which eventually call down toaac_init_adapter().If aac_init_adapter() fails after allocating memory for aac_dev::queues,it frees the memory but does not clear that member.After the hardware-specific init function returns an error,aac_probe_one() goes down an error path that frees the memory pointed toby aac_dev::queues, resulting.in a double-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: call the security_mmap_file() LSM hook in remap_file_pages()The remap_file_pages syscall handler calls do_mmap() directly, whichdoesn't contain the LSM security check. And if the process has calledpersonality(READ_IMPLIES_EXEC) before and remap_file_pages() is called forRW pages, this will actually result in remapping the pages to RWX,bypassing a W^X policy enforced by SELinux.So we should check prot by security_mmap_file LSM hook in theremap_file_pages syscall handler before do_mmap() is called. Otherwise, itpotentially permits an attacker to bypass a W^X policy enforced bySELinux.The bypass is similar to CVE-2016-10044, which bypass the same thing viaAIO and can be found in [1].The PoC:$ cat > test.cint main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd);}$ gcc test.c -o test$ ./test | grep rwx7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)[PM: subject line tweaks]
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: efifb: Register sysfs groups through driver coreThe driver core can register and cleanup sysfs groups already.Make use of that functionality to simplify the error handling andcleanup.Also avoid a UAF race during unregistering where the sysctl attributeswere usable after the info struct was freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: asihpi: Fix potential OOB array accessASIHPI driver stores some values in the static array upon a responsefrom the driver, and its index depends on the firmware. We shouldn'ttrust it blindly.This patch adds a sanity check of the array index to fit in the arraysize.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instanceDeleting an NPIV instance requires all fabric ndlps to be released beforean NPIV's resources can be torn down. Failure to release fabric ndlpsbeforehand opens kref imbalance race conditions. Fix by forcing the DA_IDto complete synchronously with usage of wait_queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When performing a symlink lookup, the grub's UFS module checks the inode's data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When reading data from a squash4 filesystem, grub's squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub's reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution, by-passing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When reading data from a jfs filesystem, grub's jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub's romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution by-passing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: When reading data from disk, the grub's UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: When reading data from a hfs filesystem, grub's hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution by-passing secure boot protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Don't reference skb after sending to VIOSPreviously, after successfully flushing the xmit buffer to VIOS,the tx_bytes stat was incremented by the length of the skb.It is invalid to access the skb memory after sending the buffer tothe VIOS because, at any point after sending, the VIOS can triggeran interrupt to free this memory. A race between reading skb->lenand freeing the skb is possible (especially during LPM) and willresult in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224==================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In SQLite 3.44.0 through 3.49.0 before 3.49.1, the concat_ws() SQL function can cause memory to be written beyond the end of a malloc-allocated buffer. If the separator argument is attacker-controlled and has a large string (e.g., 2MB or more), an integer overflow occurs in calculating the size of the result buffer, and thus malloc may not allocate enough memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsqlite3-0 < 3.49.1-9.33.1 (version in image is 3.39.3-9.26.1).
-
Description: An integer overflow can be triggered in SQLite's `concat_ws()` function. The resulting, truncated integer is then used to allocate a buffer. When SQLite then writes the resulting string to the buffer, it uses the original, untruncated size and thus a wild Heap Buffer overflow of size ~4GB can be triggered. This can result in arbitrary code execution.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsqlite3-0 < 3.49.1-9.33.1 (version in image is 3.39.3-9.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: Avoid updating block size under exclusive ownerSyzbot came up with a reproducer where a loop device block size ischanged underneath a mounted filesystem. This causes a mismatch betweenthe block device block size and the block size stored in the superblockcausing confusion in various places such as fs/buffer.c. The particularissue triggered by syzbot was a warning in __getblk_slow() due torequested buffer size not matching block device block size.Fix the problem by getting exclusive hold of the loop device to changeits block size. This fails if somebody (such as filesystem) has alreadyan exclusive ownership of the block device and thus prevents modifyingthe loop device under some exclusive owner which doesn't expect it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix race between quota disable and quota rescan ioctlThere's a race between a task disabling quotas and another running therescan ioctl that can result in a use-after-free of qgroup records fromthe fs_info->qgroup_tree rbtree.This happens as follows:1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().Also at btrfs_qgroup_rescan() don't start the rescan worker if quotaswere already disabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cnic: Fix use-after-free bugs in cnic_delete_taskThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),which does not guarantee that the delayed work item 'delete_task' hasfully completed if it was already running. Additionally, the delayed workitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() onlyblocks and waits for work items that were already queued to theworkqueue prior to its invocation. Any work items submitted afterflush_workqueue() is called are not included in the set of tasks that theflush operation awaits. This means that after the cyclic work items havefinished executing, a delayed work item may still exist in the workqueue.This leads to use-after-free scenarios where the cnic_dev is deallocatedby cnic_free_dev(), while delete_task remains active and attempt todereference cnic_dev in cnic_delete_task().A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //useReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the cyclic delayed work item is properly canceled and that anyongoing execution of the work item completes before the cnic_dev isdeallocated. Furthermore, since cancel_delayed_work_sync() uses__flush_work(work, true) to synchronously wait for any currentlyexecuting instance of the work item to finish, the flush_workqueue()becomes redundant and should be removed.This bug was identified through static analysis. To reproduce the issueand validate the fix, I simulated the cnic PCI device in QEMU andintroduced intentional delays - such as inserting calls to ssleep()within the cnic_delete_task() function - to increase the likelihoodof triggering the bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: scsi_debug: Fix type in min_t to avoid stack OOBChange min_t() to use type "u32" instead of type "int" to avoid stack outof bounds. With min_t() type "int" the values get sign extended and thelarger value gets used causing stack out of bounds.BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1Hardware name: Red Hat KVM, BIOS 1.13.0-2Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [inline] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162 fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline] resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/rdmavt: add lock to call to rvt_error_qp to prevent a race conditionThe documentation of the function rvt_error_qp says both r_lock and s_lockneed to be held when calling that function. It also asserts using lockdepthat both of those locks are held. However, the commit I referenced inFixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback nolonger covered by r_lock. This results in the lockdep assertion failingand also possibly in a race condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTSUBSAN complains about array-index-out-of-bounds:[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010[ 1.980718] kernel: Call Trace:[ 1.980721] kernel: [ 1.980723] kernel: show_stack+0x52/0x58[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f[ 1.980734] kernel: dump_stack+0x10/0x12[ 1.980736] kernel: ubsan_epilogue+0x9/0x45[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci][ 1.980748] kernel: ata_qc_issue+0x135/0x240[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580[ 1.980754] kernel: ? vprintk_default+0x1d/0x20[ 1.980759] kernel: ata_exec_internal+0x67/0xa0[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci][ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci][ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci][ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci][ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0[ 1.980813] kernel: scsi_error_handler+0xa1/0x180[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0[ 1.980820] kernel: kthread+0x12a/0x150[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50[ 1.980826] kernel: ret_from_fork+0x22/0x30[ 1.980831] kernel: This happens because sata_pmp_init_links() initialize link->pmp up toSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.I can't find the maximum Enclosure Management ports specified in AHCIspec v1.3.1, but "12.2.1 LED message type" states that "Port MultiplierInformation" can utilize 4 bits, which implies it can support up to 16ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve theissue.BugLink: https://bugs.launchpad.net/bugs/1970074
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: si470x: Fix use-after-free in si470x_int_in_callback()syzbot reported use-after-free in si470x_int_in_callback() [1]. Thisindicates that urb->context, which contains struct si470x_deviceobject, is freed when si470x_int_in_callback() is called.The cause of this issue is that si470x_int_in_callback() is called forfreed urb.si470x_usb_driver_probe() calls si470x_start_usb(), which then callsusb_submit_urb() and si470x_start(). If si470x_start_usb() fails,si470x_usb_driver_probe() doesn't kill urb, but it just frees structsi470x_device object, as depicted below:si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urbThis patch fixes this issue by killing urb when si470x_start_usb()fails and urb is submitted. If si470x_start_usb() fails and urb isnot submitted, i.e. submitting usb fails, it just frees structsi470x_device object.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Don't disable x2APIC if lockedThe APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC(or x2APIC). X2APIC mode is mostly compatible with legacy APIC, butit disables the memory-mapped APIC interface in favor of one that usesMSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.The MMIO/xAPIC interface has some problems, most notably the APIC LEAK[1]. This bug allows an attacker to use the APIC MMIO interface toextract data from the SGX enclave.Introduce support for a new feature that will allow the BIOS to lockthe APIC in x2APIC mode. If the APIC is locked in x2APIC mode and thekernel tries to disable the APIC or revert to legacy APIC mode a GPfault will occur.Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handlethe new locked mode when the LEGACY_XAPIC_DISABLED bit is set bypreventing the kernel from trying to disable the x2APIC.On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX areenabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. Iflegacy APIC is required, then it SGX and TDX need to be disabled in theBIOS.[1]: https://aepicleak.com/aepicleak.pdf
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/sit: use DEV_STATS_INC() to avoid data-racessyzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_errorconcurrently.This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()is not protected by a spinlock.While original KCSAN report was about tx path, rx path has the same issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix use after free on context disconnectionUpon module load, a kthread is created targeting thepvr2_context_thread_func function, which may call pvr2_context_destroyand thus call kfree() on the context object. However, that might happenbefore the usb hub_event handler is able to notify the driver. Thispatch adds a sanity check before the invalid read reported by syzbot,within the context disconnection call stack.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: powermate - fix use-after-free in powermate_config_completesyzbot has found a use-after-free bug [1] in the powermate driver. Thishappens when the device is disconnected, which leads to a memory free fromthe powermate_device struct. When an asynchronous control messagecompletes after the kfree and its callback is invoked, the lock does notexist anymore and hence the bug.Use usb_kill_urb() on pm->config to cancel any in-progress requests upondevice disconnection.[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Wait for io return on terminate rportSystem crash due to use after free.Current code allows terminate_rport_io to exit before makingsure all IOs has returned. For FCP-2 device, IO's can hangon in HW because driver has not tear down the session in FW atfirst sign of cable pull. When dev_loss_tmo timer pops,terminate_rport_io is called and upper layer is about tofree various resources. Terminate_rport_io trigger qla to dothe final cleanup, but the cleanup might not be fast enough where itleave qla still holding on to the same resource.Wait for IO's to return to upper layer before resources are freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Detect system inodes linked into directory hierarchyWhen UDF filesystem is corrupted, hidden system inodes can be linkedinto directory hierarchy which is an avenue for further seriouscorruption of the filesystem and kernel confusion as noticed by syzbotfuzzed images. Refuse to access system inodes linked into directoryhierarchy and vice versa.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflowA static code analysis tool flagged the possibility of buffer overflow whenusing copy_from_user() for a debugfs entry.Currently, it is possible that copy_from_user() copies more bytes than whatwould fit in the mybuf char array. Add a min() restriction check betweensizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protectagainst buffer overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- rsync < 3.1.3-3.22.1 (version in image is 3.1.3-3.14.1).
-
Description: A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: qca: add missing firmware sanity checksAdd the missing sanity checks when parsing the firmware files beforedownloading them to avoid accessing and corrupting memory beyond thevmalloced buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:enic: Validate length of nl attributes in enic_set_vf_portenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILEis of length PORT_PROFILE_MAX and that the nl attributesIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.These attributes are validated (in the function do_setlink in rtnetlink.c)using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILEas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY andIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validationusing the policy is for the max size of the attributes and not on exactsize so the length of these attributes might be less than the sizes thatenic_set_vf_port expects. This might cause an out of bandsread access in the memcpys of the data of theseattributes in enic_set_vf_port.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filelock: Remove locks reliably when fcntl/close race is detectedWhen fcntl_setlk() races with close(), it removes the created lock withdo_lock_file_wait().However, LSMs can allow the first do_lock_file_wait() that created the lockwhile denying the second do_lock_file_wait() that tries to remove the lock.Separately, posix_lock_file() could also fail toremove a lock due to GFP_KERNEL allocation failure (when splitting a rangein the middle).After the bug has been triggered, use-after-free reads will occur inlock_get_status() when userspace reads /proc/locks. This can likely be usedto read arbitrary kernel memory, but can't corrupt kernel memory.Fix it by calling locks_remove_posix() instead, which is designed toreliably get rid of POSIX locks associated with the given file andfiles_struct and is also used by filp_flush().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filelock: Fix fcntl/close race recovery compat pathWhen I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably whenfcntl/close race is detected"), I missed that there are two copies of thecode I was patching: The normal version, and the version for 64-bit offsetson 32-bit kernels.Thanks to Greg KH for stumbling over this while doing the stablebackport...Apply exactly the same fix to the compat path for 32-bit kernels.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: reject claimed-as-LCP but actually malformed packetsSince 'ppp_async_encode()' assumes valid LCP packets (with codefrom 1 to 7 inclusive), add 'ppp_check_packet()' to ensure thatLCP packet has an actual body beyond PPP_LCP header bytes, andreject claimed-as-LCP but actually malformed data otherwise.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix race condition between reset and nvme_dev_disable()nvme_dev_disable() modifies the dev->online_queues field, thereforenvme_pci_update_nr_queues() should avoid racing against it, otherwisewe could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]Fix the bug by locking the shutdown_lock mutex before usingdev->online_queues. Give up if nvme_dev_disable() is running or ifit has been executed already.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix race condition by adding filter's intermediate sync stateFix a race condition in the i40e driver that leads to MAC/VLAN filtersbecoming corrupted and leaking. Address the issue that occurs underheavy load when multiple threads are concurrently modifying MAC/VLANfilters by setting mac and port VLAN.1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan().2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac().3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption.Reproduction steps:1. Spawn multiple VFs.2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host.3. Observe errors in dmesg:"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX".Exact code for stable reproduction Intel can't open-source now.The fix involves implementing a new intermediate filter state,I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.These filters cannot be deleted from the hash list directly butmust be removed using the full process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix use-after-free of slot->bus on hot removeDennis reports a boot crash on recent Lenovo laptops with a USB4 dock.Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") andcommit 59a54c5f3dbd ("thunderbolt: Reset topology created by the bootfirmware"), USB4 v2 and v1 Host Routers are reset on probe of thethunderbolt driver.The reset clears the Presence Detect State and Data Link Layer Link Activebits at the USB4 Host Router's Root Port and thus causes hot removal of thedock.The crash occurs when pciehp is unbound from one of the dock's DownstreamPorts: pciehp creates a pci_slot on bind and destroys it on unbind. Thepci_slot contains a pointer to the pci_bus below the Downstream Port, buta reference on that pci_bus is never acquired. The pci_bus is destroyedbefore the pci_slot, so a use-after-free ensues when pci_slot_release()accesses slot->bus.In principle this should not happen because pci_stop_bus_device() unbindspciehp (and therefore destroys the pci_slot) before the pci_bus isdestroyed by pci_remove_bus_device().However the stacktrace provided by Dennis shows that pciehp is unbound frompci_remove_bus_device() instead of pci_stop_bus_device(). To understandthe significance of this, one needs to know that the PCI core uses a twostep process to remove a portion of the hierarchy: It first unbinds alldrivers in the sub-hierarchy in pci_stop_bus_device() and then actuallyremoves the devices in pci_remove_bus_device(). There is no precaution toprevent driver binding in-between pci_stop_bus_device() andpci_remove_bus_device().In Dennis' case, it seems removal of the hierarchy by pciehp races withdriver binding by pci_bus_add_devices(). pciehp is bound to theDownstream Port after pci_stop_bus_device() has run, so it is unbound bypci_remove_bus_device() instead of pci_stop_bus_device(). Because thepci_bus has already been destroyed at that point, accesses to it result ina use-after-free.One might conclude that driver binding needs to be prevented afterpci_stop_bus_device() has run. However it seems risky that pci_slot pointsto pci_bus without holding a reference. Solely relying on correct orderingof driver unbind versus pci_bus destruction is certainly not defensiveprogramming.If pci_slot has a need to access data in pci_bus, it ought to acquire areference. Amend pci_create_slot() accordingly. Dennis reports that thecrash is not reproducible with this change.Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl > 0-0 (version in image is 8.0.1-11.74.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: bpf: Add BHB mitigation to the epilogue for cBPF programsA malicious BPF program may manipulate the branch history to influencewhat the hardware speculates will happen next.On exit from a BPF program, emit the BHB mititgation sequence.This is only applied for 'classic' cBPF programs that are loaded byseccomp.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add locking for bcm_op runtime updatesThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames viahrtimer. The content and also the length of the sequence can be changedresp reduced at runtime where the 'currframe' counter is then set to zero.Although this appeared to be a safe operation the updates of 'currframe'can be triggered from user space and hrtimer context in bcm_can_tx().Anderson Nascimento created a proof of concept that triggered a KASANslab-out-of-bounds read access which can be prevented with a spin_lock_bh.At the rework of bcm_can_tx() the 'count' variable has been moved intothe protected section as this variable can be modified from both contextstoo.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio: break and reset virtio devices on device_shutdown()Hongyu reported a hang on kexec in a VM. QEMU reported invalid memoryaccesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ...It was traced down to virtio-console. Kexec works fine if virtio-consoleis not in use.The issue is that virtio-console continues to write to the MMIO even afterunderlying virtio-pci device is reset.Additionally, Eric noticed that IOMMUs are reset before devices, ifdevices are not reset on shutdown they continue to poke at guest memoryand get errors from the IOMMU. Some devices get wedged then.The problem can be solved by breaking all virtio devices on virtiobus shutdown, then resetting them.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()The hfsplus_readdir() method is capable to crash by callinghfsplus_uni2asc():[ 667.121659][ T9805] ==================================================================[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805[ 667.124578][ T9805][ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 667.124890][ T9805] Call Trace:[ 667.124893][ T9805] [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0[ 667.124911][ T9805] print_report+0xd0/0x660[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10[ 667.124942][ T9805] kasan_report+0xc6/0x100[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0[ 667.125022][ T9805] ? lock_acquire+0x30/0x80[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0[ 667.125044][ T9805] ? putname+0x154/0x1a0[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0[ 667.125069][ T9805] iterate_dir+0x296/0xb20[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0[ 667.125143][ T9805] do_syscall_64+0xc9/0x480[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 667.125207][ T9805] [ 667.125210][ T9805][ 667.145632][ T9805] Allocated by task 9805:[ 667.145991][ T9805] kasan_save_stack+0x20/0x40[ 667.146352][ T9805] kasan_save_track+0x14/0x30[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0[ 667.148174][ T9805] iterate_dir+0x296/0xb20[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0[ 667.148937][ T9805] do_syscall_64+0xc9/0x480[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 667.149809][ T9805][ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)[ 667.1---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()The hfsplus_bnode_read() method can trigger the issue:[ 174.852007][ T9784] ==================================================================[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784[ 174.854059][ T9784][ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 174.854286][ T9784] Call Trace:[ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0[ 174.854305][ T9784] print_report+0xd0/0x660[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854337][ T9784] kasan_report+0xc6/0x100[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10[ 174.854436][ T9784] ? __asan_memset+0x23/0x50[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10[ 174.854525][ T9784] ? down_write+0x148/0x200[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0[ 174.854549][ T9784] do_unlinkat+0x490/0x670[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10[ 174.854565][ T9784] ? __might_fault+0xbc/0x130[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110[ 174.854592][ T9784] do_syscall_64+0xc9/0x480[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 174.854658][ T9784] [ 174.854661][ T9784][ 174.879281][ T9784] Allocated by task 9784:[ 174.879664][ T9784] kasan_save_stack+0x20/0x40[ 174.880082][ T9784] kasan_save_track+0x14/0x30[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: udf: fix OOB read in lengthAllocDescs handlingWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes fromon-disk data and must be validated against the block size. Crafted orcorrupted images may set lengthAllocDescs so that the total descriptorlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory andtrigger a KASAN use-after-free read.BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make decode_pool() more resilient against corrupted osdmapsIf the osdmap is (maliciously) corrupted such that the encoded lengthof ceph_pg_pool envelope is less than what is expected for a particularencoding version, out-of-bounds reads may ensue because the only boundscheck that is there is based on that length value.This patch adds explicit bounds checks for each field that is decodedor skipped.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free exists in Python through 3.9 via heappushpop in heapq.
Packages affected:
- libpython2_7-1_0 < 2.7.18-33.32.1 (version in image is 2.7.18-33.26.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 < 0.6.32-32.24.1 (version in image is 0.6.32-32.18.1).
-
Description: A vulnerability was found in Avahi. A reachable assertion exists in the avahi_escape_label() function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 < 0.6.32-32.27.1 (version in image is 0.6.32-32.18.1).
-
Description: A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 < 0.6.32-32.24.1 (version in image is 0.6.32-32.18.1).
-
Description: A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 < 0.6.32-32.27.1 (version in image is 0.6.32-32.18.1).
-
Description: A vulnerability was found in Avahi. A reachable assertion exists in the avahi_alternative_host_name() function.
Packages affected:
- libavahi-client3 < 0.6.32-32.21.1 (version in image is 0.6.32-32.18.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib: cpu_rmap: Avoid use after free on rmap->obj array entriesWhen calling irq_set_affinity_notifier() with NULL at the notifyargument, it will cause freeing of the glue pointer in thecorresponding array entry but will leave the pointer in the array. Asubsequent call to free_irq_cpu_rmap() will try to free this entry againleading to possible use after free.Fix that by setting NULL to the array entry and checking that we havenon-zero at the array entry when iterating over the array infree_irq_cpu_rmap().The current code does not suffer from this since there are no caseswhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for thenotify arg) is called, followed by a call to free_irq_cpu_rmap() so wedon't hit and issue. Subsequent patches in this series excersize thisflow, hence the required fix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix an uninit variable access bug in __ip6_make_skb()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because icmp6hdr does not in skb linear region under the scenarioof SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly willtrigger the uninit variable access bug.Use a local variable icmp6_type to carry the correct value in differentscenarios.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: NULL Pointer Dereference in GitHub repository vim/vim prior to 20d161ace307e28690229b68584f2d84556f8960.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.0.2103-17.26.1 (version in image is 9.0.1894-17.23.2).
-
Description: An issue was found in the CPython `zipfile` module affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.The zipfile module is vulnerable to "quoted-overlap" zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.130.1 (version in image is 3.4.10-25.116.1).
-
Description: The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-osconfig-agent < 20250115.01-1.32.1 (version in image is 20230706.02-1.23.3).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sr9800: Add check for usbnet_get_endpointsAdd check for usbnet_get_endpoints() and return the error if it failsin order to transfer the error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: nscd: netgroup cache may terminate daemon on memory allocation failureThe Name Service Cache Daemon's (nscd) netgroup cache uses xmalloc orxrealloc and these functions may terminate the process due to a memoryallocation failure resulting in a denial of service to the clients. Theflaw was introduced in glibc 2.15 when the cache was added to nscd.This vulnerability is only present in the nscd binary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc < 2.22-114.34.1 (version in image is 2.22-114.31.1).
-
Description: url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- wget < 1.14-21.19.1 (version in image is 1.14-21.13.2).
-
Description: An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat < 2.1.0-21.37.1 (version in image is 2.1.0-21.28.1).
-
Description: An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat < 2.1.0-21.37.1 (version in image is 2.1.0-21.28.1).
-
Description: An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat < 2.1.0-21.37.1 (version in image is 2.1.0-21.28.1).
-
Description: FreeType 2.8.1 has a signed integer overflow in cf2_doFlex in cff/cf2intrp.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libfreetype6 > 0-0 (version in image is 2.6.3-7.18.1).
-
Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- perl > 0-0 (version in image is 5.18.2-12.26.1).
-
Description: In the urllib3 library through 1.24.1 for Python, CRLF injection is possible if the attacker controls the request parameter.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix data corruption after conversion from inline formatCommit 6dbf7bb55598 ("fs: Don't invalidate page buffers inblock_write_full_page()") uncovered a latent bug in ocfs2 conversionfrom inline inode format to a normal inode format.The code in ocfs2_convert_inline_data_to_extents() attempts to zero outthe whole cluster allocated for file data by grabbing, zeroing, anddirtying all pages covering this cluster. However these pages arebeyond i_size, thus writeback code generally ignores these dirty pagesand no blocks were ever actually zeroed on the disk.This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zeropages past i_size.") for standard ocfs2 write path, inline conversionpath was apparently forgotten; the commit log also has a reasoning whythe zeroing actually is not needed.After commit 6dbf7bb55598, things became worse as writeback code stoppedinvalidating buffers on pages beyond i_size and thus these pages end upwith clean PageDirty bit but with buffers attached to these pages beingstill dirty. So when a file is converted from inline format, thenwriteback triggers, and then the file is grown so that these pagesbecome valid, the invalid dirtiness state is preserved,mark_buffer_dirty() does nothing on these pages (buffers are alreadydirty) but page is never written back because it is clean. So datawritten to these pages is lost once pages are reclaimed.Simple reproducer for the problem is: xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_fileAfter unmounting and mounting the fs again, you can observe that end of'ocfs2_file' has lost its contents.Fix the problem by not doing the pointless zeroing during conversionfrom inline format similarly as in the standard write path.[akpm@linux-foundation.org: fix whitespace, per Joseph]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix page frag corruption on page faultSteffen reported a TCP stream corruption for HTTP requestsserved by the apache web-server using a cifs mount-pointand memory mapping the relevant file.The root cause is quite similar to the one addressed bycommit 20eb4f29b602 ("net: fix sk_page_frag() recursion frommemory reclaim"). Here the nested access to the task page fragis caused by a page fault on the (mmapped) user-space memorybuffer coming from the cifs file.The page fault handler performs an smb transaction on a differentsocket, inside the same process context. Since sk->sk_allactionfor such socket does not prevent the usage for the task_frag,the nested allocation modify "under the hood" the page fragin use by the outer sendmsg call, corrupting the stream.The overall relevant stack trace looks like the following:httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: ffffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139814e sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 __handle_mm_fault+0x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copy_from_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 ffffffff90f2dff0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,we can avoid the nesting using the sk page frag for allocationlacking the __GFP_FS flag. Do not define an additional mm-helperfor that, as this is strictly tied to the sk page frag usage.v1 -> v2: - use a stricted sk_page_frag() check instead of reordering the code (Eric)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: remove vsock from connected table when connect is interrupted by a signalvsock_connect() expects that the socket could already be in theTCP_ESTABLISHED state when the connecting task wakes up with a signalpending. If this happens the socket will be in the connected table, andit is not removed when the socket state is reset. In this situation it'scommon for the process to retry connect(), and if the connection issuccessful the socket will be added to the connected table a secondtime, corrupting the list.Prevent this by calling vsock_remove_connected() if a signal is receivedwhile waiting for a connection. This is harmless if the socket is not inthe connected table, and if it is in the table then removing it willprevent list corruption from a double add.Note for backporting: this patch requires d5afa82c977e ("vsock: correctremoval of socket from the list"), which is in all current stable treesexcept 4.9.y.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvneta: Prevent out of bounds read in mvneta_config_rss()The pp->indir[0] value comes from the user. It is passed to: if (cpu_online(pp->rxq_def))inside the mvneta_percpu_elect() function. It needs bounds checkedingto ensure that it is not beyond the end of the cpu bitmap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: fix panic on out-of-bounds guest IRQAs guest_irq is coming from KVM_IRQFD API call, it may triggercrash in svm_update_pi_irte() due to out-of-bounds:crash> btPID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002bVmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() onout-of-bounds guest IRQ), so we can just copy source from that to fixthis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Allow waiting for commands to complete on removed deviceWhen a SCSI device is removed while in active use, currently sg willimmediately return -ENODEV on any attempt to wait for active commands thatwere sent before the removal. This is problematic for commands that useSG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernelwhen userspace frees or reuses it after getting ENODEV, leading tocorrupted userspace memory (in the case of READ-type commands) or corrupteddata being sent to the device (in the case of WRITE-type commands). Thishas been seen in practice when logging out of a iscsi_tcp session, wherethe iSCSI driver may still be processing commands after the device has beenmarked for removal.Change the policy to allow userspace to wait for active sg commands evenwhen the device is being removed. Return -ENODEV only when there are nomore responses to read.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: prevent overflow while calculating wait timeThere is a problem found by code review in tg_with_in_bps_limit() that'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem bycalling mul_u64_u64_div_u64() instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Clear nfc_target before being usedFix a slab-out-of-bounds read that occurs in nla_put() called fromnfc_genl_send_target() when target->sensb_res_len, which is duplicatedfrom an nfc_target in pn533, is too large as the nfc_target is notproperly initialized and retains garbage values. Clear nfc_targets withmemset() before they are used.Found by a modified version of syzkaller.BUG: KASAN: slab-out-of-bounds in nla_putCall Trace: memcpy nla_put nfc_genl_dump_targets genl_lock_dumpit netlink_dump __netlink_dump_start genl_family_rcv_msg_dumpit genl_rcv_msg netlink_rcv_skb genl_rcv netlink_unicast netlink_sendmsg sock_sendmsg ____sys_sendmsg ___sys_sendmsg __sys_sendmsg do_syscall_64
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], forioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() withpkt_len = 0 but ath9k_hif_usb_rx_stream() uses__dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption thatpkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skbwith uninitialized memory and ath9k_htc_rx_msg() is reading fromuninitialized memory.Since bytes accessed by ath9k_htc_rx_msg() is not known untilath9k_htc_rx_msg() is called, it would be difficult to check minimal validpkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line inath9k_hif_usb_rx_stream().We have two choices. One is to workaround by adding __GFP_ZERO so thatath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to letath9k_htc_rx_msg() validate pkt_len before accessing. This patch chosethe latter.Note that I'm not sure threshold condition is correct, for I can't finddetails on possible packet length used by this protocol.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Fix UAF in bcm_proc_show()BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80Read of size 8 at addr ffff888155846230 by task cat/7862CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdAllocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdFreed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0bcm_op is freed before procfs entry be removed in bcm_release(),this lead to bcm_proc_show() may read the freed bcm_op.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Add length check when parsing nlattrsThere are three places that qla4xxx parses nlattrs: - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param()and each of them directly converts the nlattr to specific pointer ofstructure without length checking. This could be dangerous as thoseattributes are not validated and a malformed nlattr (e.g., length 0) couldresult in an OOB read that leaks heap dirty data.Add the nla_len check before accessing the nlattr data and return EINVAL ifthe length check fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-boundsFix a stack-out-of-bounds read in brcmfmac that occurswhen 'buf' that is not null-terminated is passed as an argument ofstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled witha CLM version string by memcpy() in brcmf_fil_iovar_data_get().Ensure buf is null-terminated.Found by a modified version of syzkaller.[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22[ 33.021554][ T1896] ==================================================================[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896[ 33.023852][ T1896][ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event[ 33.026581][ T1896] Call Trace:[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334[ 33.028037][ T1896] ? strreplace+0xf2/0x110[ 33.028403][ T1896] ? strreplace+0xf2/0x110[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf[ 33.029283][ T1896] ? strreplace+0xf2/0x110[ 33.029666][ T1896] strreplace+0xf2/0x110[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0[ 33.033582][ T1896] brcmf_attach+0x246/0xd40[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50[ 33.034383][ T1896] ? kmemdup+0x30/0x40[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710[ 33.036315][ T1896] really_probe+0x1be/0xa90[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0[ 33.037383][ T1896] driver_probe_device+0x49/0x120[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120[ 33.042330][ T1896] __device_attach+0x207/0x330[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260[ 33.043914][ T1896] device_add+0xa61/0x1ce0[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90[ 33.046931][ T1896] usb_probe_device+0x9c/0x220[ 33.047434][ T1896] really_probe+0x1be/0xa90[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460[ 33.048134][ T1896] driver_probe_device+0x49/0x120[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_fq: fix integer overflow of "credit"if sch_fq is configured with "initial quantum" having values greater thanINT_MAX, the first assignment of "credit" does signed integer overflow toa very negative value.In this situation, the syzkaller script provided by Cristoph triggers theCPU soft-lockup warning even with few sockets. It's not an infinite loop,but "credit" wasn't probably meant to be minus 2Gb for each new flow.Capping "initial quantum" to INT_MAX proved to fix the issue.v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix wrong ct->timeout value(struct nf_conn)->timeout is an interval before the conntrackconfirmed. After confirmed, it becomes a timestamp.It is observed that timeout of an unconfirmed conntrack:- Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice.- Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted.Call Trace: dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsgSeparate the 2 cases in:- Setting `ct->timeout` in __nf_ct_set_timeout().- Getting `ct->timeout` in ctnetlink_dump_timeout().Pablo appends:Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag isset on, otherwise conntrack creation via ctnetlink breaks.Note that the problem described in this patch occurs since theintroduction of the nfnetlink_queue conntrack support, select asufficiently old Fixes: tag for -stable kernel to pick up this fix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cdc_ncm: Deal with too low values of dwNtbOutMaxSizeCurrently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower thanthe calculated "min" value, but greater than zero, the logic setstx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB incdc_ncm_fill_tx_frame() where all the data is handled.For small values of dwNtbOutMaxSize the memory allocated duringalloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due tohow size is aligned at alloc time: size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));Thus we hit the same bug that we tried to squash withcommit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")Low values of dwNtbOutMaxSize do not cause an issue presently because atalloc_skb() time more memory (512b) is allocated than required for theSKB headers alone (320b), leaving some space (512b - 320b = 192b)for CDC data (172b).However, if more elements (for example 3 x u64 = [24b]) were added toone of the SKB header structs, say 'struct skb_shared_info',increasing its original size (320b [320b aligned]) to something larger(344b [384b aligned]), then suddenly the CDC data (172b) no longerfits in the spare SKB data area (512b - 384b = 128b).Consequently the SKB bounds checking semantics fails and panics:skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:------------[ cut here ]------------kernel BUG at net/core/skbuff.c:113!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023Workqueue: mld mld_ifc_workRIP: 0010:skb_panic net/core/skbuff.c:113 [inline]RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118[snip]Call Trace: skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100Deal with too low values of dwNtbOutMaxSize, clamp it in the range[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensureenough data space is allocated to handle CDC data by making suredwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/net_failover: fix txq exceeding warningThe failover txq is inited as 16 queues.when a packet is transmitted from the failover device firstly,the failover device will select the queue which is returned fromthe primary device if the primary device is UP and running.If the primary device txq is bigger than the default 16,it can lead to the following warning:eth0 selects TX queue 18, but real number of TX queues is 16The warning backtrace is:[ 32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G E 6.2.8-1.el7.centos.x86_64 #1[ 32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014[ 32.147730] Call Trace:[ 32.147971] [ 32.148183] dump_stack_lvl+0x48/0x70[ 32.148514] dump_stack+0x10/0x20[ 32.148820] netdev_core_pick_tx+0xb1/0xe0[ 32.149180] __dev_queue_xmit+0x529/0xcf0[ 32.149533] ? __check_object_size.part.0+0x21c/0x2c0[ 32.149967] ip_finish_output2+0x278/0x560[ 32.150327] __ip_finish_output+0x1fe/0x2f0[ 32.150690] ip_finish_output+0x2a/0xd0[ 32.151032] ip_output+0x7a/0x110[ 32.151337] ? __pfx_ip_finish_output+0x10/0x10[ 32.151733] ip_local_out+0x5e/0x70[ 32.152054] ip_send_skb+0x19/0x50[ 32.152366] udp_send_skb.isra.0+0x163/0x3a0[ 32.152736] udp_sendmsg+0xba8/0xec0[ 32.153060] ? __folio_memcg_unlock+0x25/0x60[ 32.153445] ? __pfx_ip_generic_getfrag+0x10/0x10[ 32.153854] ? sock_has_perm+0x85/0xa0[ 32.154190] inet_sendmsg+0x6d/0x80[ 32.154508] ? inet_sendmsg+0x6d/0x80[ 32.154838] sock_sendmsg+0x62/0x70[ 32.155152] ____sys_sendmsg+0x134/0x290[ 32.155499] ___sys_sendmsg+0x81/0xc0[ 32.155828] ? _get_random_bytes.part.0+0x79/0x1a0[ 32.156240] ? ip4_datagram_release_cb+0x5f/0x1e0[ 32.156649] ? get_random_u16+0x69/0xf0[ 32.156989] ? __fget_light+0xcf/0x110[ 32.157326] __sys_sendmmsg+0xc4/0x210[ 32.157657] ? __sys_connect+0xb7/0xe0[ 32.157995] ? __audit_syscall_entry+0xce/0x140[ 32.158388] ? syscall_trace_enter.isra.0+0x12c/0x1a0[ 32.158820] __x64_sys_sendmmsg+0x24/0x30[ 32.159171] do_syscall_64+0x38/0x90[ 32.159493] entry_SYSCALL_64_after_hwframe+0x72/0xdcFix that by reducing txq number as the non-existent primary-dev does.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ebtables: fix table blob use-after-freeWe are not allowed to return an error at this point.Looking at the code it looks like ret is always 0 at thispoint, but its not.t = find_table_lock(net, repl->name, &ret, &ebt_mutex);... this can return a valid table, with ret != 0.This bug causes update of table->private with the newblob, but then frees the blob right away in the caller.Syzbot report:BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74Workqueue: netns cleanup_netCall Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613...ip(6)tables appears to be ok (ret should be 0 at this point) but makethis more obvious.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds read vulnerability was found in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.189.1 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- wget > 0-0 (version in image is 1.14-21.13.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:llc: Drop support for ETH_P_TR_802_2.syzbot reported an uninit-value bug below. [0]llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2(0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)llc_conn_handler() initialises local variables {saddr,daddr}.macbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passesthem to __llc_lookup().However, the initialisation is done only when skb->protocol ishtons(ETH_P_802_2), otherwise, __llc_lookup_established() and__llc_lookup_listener() will read garbage.The missing initialisation existed prior to commit 211ed865108e("net: delete all instances of special processing for token ring").It removed the part to kick out the token ring stuff but forgot toclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let's remove llc_tr_packet_type and complete the deprecation.[0]:BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bLocal variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].Call pskb_inet_may_pull() to fix this, and initialize ipv6hvariable after this call as it can change skb->head.[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg"at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237Some code commentry, based on my understanding:544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size)/// This is 24 + payload_sizememcpy(&dg_info->msg, dg, dg_size); Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size{payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32. 35 struct delayed_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg; 41 u8 msg_payload[]; 42 };So those extra bytes of payload are copied into msg_payload[], a run timewarning is seen while fuzzing with Syzkaller.One possible way to fix the warning is to split the memcpy() intotwo parts -- one -- direct assignment of msg and second taking care of payload.Gustavo quoted:"Under FORTIFY_SOURCE we should not copy data across multiple membersin a structure."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validationEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be astruct ifla_vf_vlan_info so the size of such attribute needs to be at leastof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)which is less than sizeof(struct ifla_vf_vlan_info) so this validationis not enough and a too small attribute might be cast to astruct ifla_vf_vlan_info, this might result in an out of bandsread access when accessing the saved (casted) entry in ivvl.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()The app_reply->elem[] array is allocated earlier in this function and ithas app_req.num_ports elements. Thus this > comparison needs to be >= toprevent memory corruption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix UAF in error pathSam Page (sam4k) working with Trend Micro Zero Day Initiative reporteda UAF in the tipc_buf_append() error path:BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0linux/net/core/skbuff.c:1183Read of size 8 at addr ffff88804d2a7c80 by task poc/8034CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.0-debian-1.16.0-5 04/01/2014Call Trace: __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_---truncated---
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: llcp: fix nfc_llcp_setsockopt() unsafe copiessyzbot reported unsafe calls to copy_from_sockptr() [1]Use copy_safe_from_sockptr() instead.[1]BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfd/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75RIP: 0033:0x7f7fac07fd89Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix invalid reads in fence signaled eventsCorrectly set the length of the drm_event to the size of the structurethat's actually used.The length of the drm_event was set to the parent structure instead ofto the drm_vmw_event_fence which is supposed to be read. drm_readuses the length parameter to copy the event to the user space thusresuling in oob reads.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix crash on racing fsync and size-extending write into preallocWe have been seeing crashes on duplicate keys inbtrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)So we're logging a changed extent from fsync, which is splitting anextent in the log tree. But this split part already exists in the tree,triggering the BUG().This is the state of the log tree at the time of the crash, dumped withdrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ...So the real problem happened earlier: notice that items 4 (4k-12k) and 5(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size anditem 5 starts at i_size.Here is the state of ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential index out of bounds in color transformation functionFixes index out of bounds issue in the color transformation function.The issue could occur when the index 'i' exceeds the number of transferfunction points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds, an error message islogged and the function returns false to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ecryptfs: Fix buffer size for tag 66 packetThe 'TAG 66 Packet Format' description is missing the cipher code andchecksum fields that are packed into the message packet. As a result,the buffer allocated for the packet is 3 bytes too small andwrite_tag_66_packet() will write up to 3 bytes past the end of thebuffer.Fix this by increasing the size of the allocation so the whole packetwill always fit in the buffer.This fixes the below kasan slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ? __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 ? __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 ? __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ? __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ? __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10 __x64_sys_openat+0xef/0x170 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 Allocated by task 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - Fix pointer arithmeticIn spu2_dump_omd() value of ptr is increased by ciph_key_leninstead of hash_iv_len which could lead to going beyond thebuffer boundaries.Fix this bug by changing ciph_key_len to hash_iv_len.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()In function bond_option_arp_ip_targets_set(), if newval->string is anempty string, newval->string+1 will point to the byte after thestring, causing an out-of-bound read.BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b---[ end trace ]---Fix it by adding a check of string length before using it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86: stop playing stack games in profile_pc()The 'profile_pc()' function is used for timer-based profiling, whichisn't really all that relevant any more to begin with, but it also endsup making assumptions based on the stack layout that aren't necessarilyvalid.Basically, the code tries to account the time spent in spinlocks to thecaller rather than the spinlock, and while I support that as a concept,it's not worth the code complexity or the KASAN warnings when no seriousprofiling is done using timers anyway these days.And the code really does depend on stack layout that is only true in thesimplest of cases. We've lost the comment at some point (I think whenthe 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF.which explains why it just blindly loads a word or two straight off thestack pointer and then takes a minimal look at the values to just checkif they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addressesbut that basic stack layout assumption assumes that there isn't any lockdebugging etc going on that would complicate the code and cause a stackframe.It causes KASAN unhappiness reported for years by syzkaller [1] andothers [2].With no real practical reason for this any more, just remove the code.Just for historical interest, here's some background commits relating tothis code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc")but the basics of this thing actually goes back to before the git tree.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Fix Virtual Memory mapping boundaries calculationCalculating the size of the mapped area as the lesser valuebetween the requested size and the actual size does not considerthe partial mapping offset. This can cause page fault access.Fix the calculation of the starting and ending addresses, thetotal size is now deduced from the difference between the end andstart addresses.Additionally, the calculations have been rewritten in a clearerand more understandable form.[Joonas: Add Requires: tag]Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efistub/tpm: Use ACPI reclaim memory for event log to avoid corruptionThe TPM event log table is a Linux specific construct, where the dataproduced by the GetEventLog() boot service is cached in memory, andpassed on to the OS using an EFI configuration table.The use of EFI_LOADER_DATA here results in the region being leftunreserved in the E820 memory map constructed by the EFI stub, and thisis the memory description that is passed on to the incoming kernel bykexec, which is therefore unaware that the region should be reserved.Even though the utility of the TPM2 event log after a kexec isquestionable, any corruption might send the parsing code off into theweeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORYinstead, which is always treated as reserved by the E820 conversionlogic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Fix uninitialized value issue in from_kuid and from_kgidocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid ina trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.Initialize all fields of newattrs to avoid uninitialized variables, bychecking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libblkid1 > 0-0 (version in image is 2.33.2-4.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free when attempting to join an aborted transactionWhen we are trying to join the current transaction and if it's aborted,we read its 'aborted' field after unlocking fs_info->trans_lock andwithout holding any extra reference count on it. This means that aconcurrent task that is aborting the transaction may free the transactionbefore we read its 'aborted' field, leading to a use-after-free.Fix this by reading the 'aborted' field while holding fs_info->trans_locksince any freeing task must first acquire that lock and setfs_info->running_transaction to NULL before freeing the transaction.This was reported by syzbot and Dmitry with the following stack tracesfrom KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: Fix KMSAN uninit-value warning with bpfSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by theppp driver not initializing a 2-byte header when using socket filter.The following code can generate a PPP filter BPF program:'''struct bpf_program fp;pcap_t *handle;handle = pcap_open_dead(DLT_PPP_PPPD, 65535);pcap_compile(handle, &fp, "ip and outbound", 0, 0);bpf_dump(&fp, 1);'''Its output is:'''(000) ldh [2](001) jeq #0x21 jt 2 jf 5(002) ldb [0](003) jeq #0x1 jt 4 jf 5(004) ret #65535(005) ret #0'''Wen can find similar code at the following link:https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680The maintainer of this code repository is also the original maintainerof the ppp driver.As you can see the BPF program skips 2 bytes of data and then reads the'Protocol' field to determine if it's an IP packet. Then it read the firstbyte of the first 2 bytes to determine the direction.The issue is that only the first byte indicating direction is initializedin current ppp driver code while the second byte is not initialized.For normal BPF programs generated by libpcap, uninitialized data won't beused, so it's not a problem. However, for carefully crafted BPF programs,such as those generated by syzkaller [2], which start reading from offset0, the uninitialized data will be used and caught by KMSAN.[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the 'function_graph' tracer to the'timerlat' tracer, s_start only calls graph_trace_close of the'function_graph' tracer to free 'iter->private', but does not setit to NULL. This provides an opportunity for 'event->funcs->trace()'to use an invalid 'iter->private'.To fix this issue, set 'iter->private' to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary'iter->private = NULL' during each 'cat trace' when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press 'x' on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.1406-17.48.1 (version in image is 9.0.1894-17.23.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[pabeni@redhat.com: fixed subj typo]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lzo - Fix compression buffer overrunUnlike the decompression code, the compression code in LZO neverchecked for output overruns. It instead assumes that the calleralways provides enough buffer space, disregarding the buffer lengthprovided by the caller.Add a safe compression interface that checks for the end of bufferbefore each write. Use the safe interface in crypto/lzo.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: clear the dst when changing skb protocolA not-so-careful NAT46 BPF program can crash the kernelif it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10)The output interface has a 4->6 program attached at ingress.We try to loop the multicast skb back to the sending socket.Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdrand changes skb->protocol to v6. We enter ip6_rcv_core whichtries to use skb_dst(). But the dst is still an IPv4 one leftafter IPv4 mcast output.Clear the dst in all BPF helpers which change the protocol.Try to preserve metadata dsts, those may carry non-routingmetadata.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: reject invalid perturb periodGerrard Tai reported that SFQ perturb_period has no range check yet,and this can be used to trigger a race condition fixed in a separate patch.We want to make sure ctl->perturb_period * HZ will not overflowand is positive.tc qd add dev lo root sfq perturb -10 # negative value : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 1000000000 # too big : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 2000000 # acceptable valuetc -s -d qd sh dev loqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix use-after-free of work objects after cm_id destructionThe commit 59c68ac31e15 ("iw_cm: free cm_id resources on the lastderef") simplified cm_id resource management by freeing cm_id once allreferences to the cm_id were removed. The references are removed eitherupon completion of iw_cm event handlers or when the application destroysthe cm_id. This commit introduced the use-after-free condition wherecm_id_private object could still be in use by event handler works duringthe destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix ause-after-free related to destroying CM IDs") addressed this use-after-free by flushing all pending works at the cm_id destruction.However, still another use-after-free possibility remained. It happenswith the work objects allocated for each cm_id_priv withinalloc_work_entries() during cm_id creation, and subsequently freed indealloc_work_entries() once all references to the cm_id are removed.If the cm_id's last reference is decremented in the event handler work,the work object for the work itself gets removed, and causes the use-after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30This BUG is reproducible by repeating the blktests test case nvme/061for the rdma transport and the siw driver.To avoid the use-after-free of cm_id_private work objects, ensure thatthe last reference to the cm_id is decremented not in the event handlerworks, but in the cm_id destruction context. For that purpose, mo---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: inline: fix len overflow in ext4_prepare_inline_dataWhen running the following code on an ext4 filesystem with inline_datafeature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL);That happens because write_begin will succeed as whenext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + lenwill be truncated, leading to ext4_prepare_inline_data parameter to be 6instead of 0x10000000006.Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);at ext4_write_inline_data.Fix it by using a loff_t type for the len parameter inext4_prepare_inline_data instead of an unsigned int.[ 44.545164] ------------[ cut here ]------------[ 44.545530] kernel BUG at fs/ext4/inline.c:240![ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0[ 44.546523] PKRU: 55555554[ 44.546523] Call Trace:[ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0[ 44.546523] generic_perform_write+0x17e/0x270[ 44.546523] ext4_buffered_write_iter+0xc8/0x170[ 44.546523] vfs_write+0x2be/0x3e0[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0[ 44.546523] do_syscall_64+0x6a/0xf0[ 44.546523] ? __wake_up+0x89/0xb0[ 44.546523] ? xas_find+0x72/0x1c0[ 44.546523] ? next_uptodate_folio+0x317/0x330[ 44.546523] ? set_pte_range+0x1a6/0x270[ 44.546523] ? filemap_map_pages+0x6ee/0x840[ 44.546523] ? ext4_setattr+0x2fa/0x750[ 44.546523] ? do_pte_missing+0x128/0xf70[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0[ 44.546523] ? ___pte_offset_map+0x19/0x100[ 44.546523] ? handle_mm_fault+0x721/0xa10[ 44.546523] ? do_user_addr_fault+0x197/0x730[ 44.546523] ? do_syscall_64+0x76/0xf0[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 44.546523] RIP: 0033:0x7f42999c6687[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()In snd_usb_get_audioformat_uac3(), the length value returned fromsnd_usb_ctl_msg() is used directly for memory allocation withoutvalidation. This length is controlled by the USB device.The allocated buffer is cast to a uac3_cluster_header_descriptorand its fields are accessed without verifying that the bufferis large enough. If the device returns a smaller than expectedlength, this leads to an out-of-bounds read.Add a length check to ensure the buffer is large enough foruac3_cluster_header_descriptor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/vmci: Clear the vmci transport packet properly when initializing itIn vmci_transport_packet_init memset the vmci_transport_packet beforepopulating the fields to avoid any uninitialised data being left in thestructure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in i40e_validate_queue_mapEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_validate_queue_map().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattrCurrently when both IMA and EVM are in fix mode, the IMA signature willbe reset to IMA hash if a program first stores IMA signature insecurity.ima and then writes/removes some other security xattr for thefile.For example, on Fedora, after booting the kernel with "ima_appraise=fixevm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,installing/reinstalling a package will not make good reference IMAsignature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404...This happens because when setting security.selinux, the IMA_DIGSIG flagthat had been set early was cleared. As a result, IMA hash is generatedwhen the file is closed.Similarly, IMA signature can be cleared on file close after removingsecurity xattr like security.evm or setting/removing ACL.Prevent replacing the IMA file signature with a file hash, by preventingthe IMA_DIGSIG flag from being reset.Here's a minimal C reproducer which sets security.selinux as the laststep which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:via_wdt: fix critical boot hang due to unnamed resource allocationThe VIA watchdog driver uses allocate_resource() to reserve a MMIOregion for the watchdog control register. However, the allocatedresource was not given a name, which causes the kernel resource treeto contain an entry marked as "" under /proc/iomem on x86platforms.During boot, this unnamed resource can lead to a critical hang becausesubsequent resource lookups and conflict checks fail to handle theinvalid entry properly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Fix use-after-free in gsm_cleanup_muxBUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0drivers/tty/n_gsm.c:3160 [n_gsm]Read of size 8 at addr ffff88815fe99c00 by task poc/3379CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56Hardware name: VMware, Inc. VMware Virtual Platform/440BXDesktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818[Analysis]gsm_msg on the tx_ctrl_list or tx_data_list of gsm_muxcan be freed by multi threads through ioctl,which leadsto the occurrence of uaf. Protect it by gsm tx lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: scomp - fix req->dst buffer overflowThe req->dst buffer size should be checked before copying from thescomp_scratch->dst to avoid req->dst buffer overflow problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: betop: fix slab-out-of-bounds Write in betop_probeSyzbot reported slab-out-of-bounds Write bug in hid-betopff driver.The problem is the driver assumes the device must have an input report butsome malicious devices violate this assumption.So this patch checks hid_device's input is non empty before it's been used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211: fix potential double free on mesh joinWhile commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leavingmesh") fixed a memory leak on mesh leave / teardown it introduced apotential memory corruption caused by a double free when rejoining themesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie);This double free / kernel panics can be reproduced by using wpa_supplicantwith an encrypted mesh (if set up without encryption via "iw" thenifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-meshNote that typically these commands are not used / working when usingwpa_supplicant. And it seems that wpa_supplicant or wpa_cli are goingthrough a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh joinwhere the NETDEV_UP resets the mesh.ie to NULL via a memcpy ofdefault_mesh_setup in cfg80211_netdev_notifier_call, which then avoidsthe memory corruption, too.The issue was first observed in an application which was not usingwpa_supplicant but "Senf" instead, which implements its own calls tonl80211.Fixing the issue by removing the kfree()'ing of the mesh IE in the meshjoin function and leaving it solely up to the mesh leave to free themesh IE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid resizing to a partial cluster sizeThis patch avoids an attempt to resize the filesystem to anunaligned cluster boundary. An online resize to a size that is notintegral to cluster size results in the last iteration attempting togrow the fs by a negative amount, which trips a BUG_ON and leaves the fswith a corrupted in-memory superblock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-requests < 2.24.0-8.20.1 (version in image is 2.24.0-8.14.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Don't free decrypted memoryIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus device UIO driver could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the gpadlto decide whether to free the memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware_loader: Block path traversalMost firmware names are hardcoded strings, or are constructed from fairlyconstrained format strings where the dynamic parts are just some hexnumbers or such.However, there are a couple codepaths in the kernel where firmware filenames contain string components that are passed through from a device orsemi-privileged userspace; the ones I could find (not counting interfacesthat require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.)Fix it by rejecting any firmware names containing ".." path components.For what it's worth, I went looking and haven't found any USB devicedrivers that use the firmware loader dangerously.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix OOB read when checking dotdot dirMounting a corrupted filesystem with directory which contains '.' direntry with rec_len == block size results in out-of-bounds read (lateron, when the corrupted directory is removed).ext4_empty_dir() assumes every ext4 directory contains at least '.'and '..' as directory entries in the first data block. It first loadsthe '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()and then uses its rec_len member to compute the location of '..' direntry (in ext4_next_entry). It assumes the '..' dir entry fits into thesame data block.If the rec_len of '.' is precisely one block (4KB), it slips through thesanity checks (it is considered the last directory entry in the datablock) and leaves "struct ext4_dir_entry_2 *de" point exactly past thememory slot allocated to the data block. The following call toext4_check_dir_entry() on new value of de then dereferences this pointerwhich results in out-of-bounds mem access.Fix this by extending __ext4_check_dir_entry() to check for '.' direntries that reach the end of data block. Make sure to ignore the phonydir entries for checksum (by checking name_len for non-zero).Note: This is reported by KASAN as use-after-free in case anotherstructure was recently freed from the slot past the bound, but it isreally an OOB read.This issue was found by syzkaller tool.Call Trace:[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375[ 38.595158][ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 38.595304] Call Trace:[ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710[ 38.595349] print_report+0xaa/0x250[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710[ 38.595368] ? kasan_addr_to_slab+0x9/0x90[ 38.595378] kasan_report+0xab/0xe0[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710[ 38.595400] __ext4_check_dir_entry+0x67e/0x710[ 38.595410] ext4_empty_dir+0x465/0x990[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10[ 38.595478] ? down_write+0xdb/0x140[ 38.595487] ? __pfx_down_write+0x10/0x10[ 38.595497] ext4_rmdir+0xee/0x140[ 38.595506] vfs_rmdir+0x209/0x670[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190[ 38.595529] do_rmdir+0x363/0x3c0[ 38.595537] ? __pfx_do_rmdir+0x10/0x10[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0[ 38.595561] __x64_sys_unlinkat+0xf0/0x130[ 38.595570] do_syscall_64+0x5b/0x180[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix MMIO write access to an invalid page in i40e_clear_hwWhen the device sends a specific input, an integer underflow can occur, leadingto MMIO write access to an invalid page.Prevent the integer underflow by changing the type of related variables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: fix potential buffer overflow in do_register_framebuffer()The current implementation may lead to buffer overflow when:1. Unregistration creates NULL gaps in registered_fb[]2. All array slots become occupied despite num_registered_fb < FB_MAX3. The registration loop exceeds array boundsAdd boundary check to prevent registered_fb[FB_MAX] access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/buffer: fix use-after-free when call bh_read() helperThere's issue as follows:BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer wait_on_buffer(bh);--> return will return to caller put_bh --> trigger stack-out-of-boundsIn the mpage_read_folio() function, the stack variable 'map_bh' ispassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks andwait_on_buffer() returns to continue processing, the stack variableis likely to be reclaimed. Consequently, during the end_buffer_read_sync()process, calling put_bh() may result in stack overrun.If the bh is not allocated on the stack, it belongs to a folio. Freeinga buffer head which belongs to a folio is done by drop_buffers() whichwill fail to free buffers which are still locked. So it is safe to callput_bh() before __end_buffer_read_notouch().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- screen > 0-0 (version in image is 4.0.4-23.6.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- cups-libs > 0-0 (version in image is 1.7.5-20.46.1).
-
Description: The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: It was found that the GnuTLS implementation of HMAC-SHA-384 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets.
Packages affected:
- libgnutls30 > 0-0 (version in image is 3.4.17-8.14.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: libssh 0.9.4 has a NULL pointer dereference in tftpserver.c if ssh_buffer_new returns NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: An issue was discovered in compare_digest in Lib/hmac.py in Python through 3.9.1. Constant-time-defeating optimisations were possible in the accumulator variable in hmac.compare_digest.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_6m1_0 < 3.6.15-55.1 (version in image is 3.6.15-49.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Update ipcomp_scratches with NULL when freedCurrently if ipcomp_alloc_scratches() fails to allocate memoryipcomp_scratches holds obsolete address. So when we try to free thepercpu scratches using ipcomp_free_scratches() it tries to vfree nonexistent vm area. Described below:static void * __percpu *ipcomp_alloc_scratches(void){ ... scratches = alloc_percpu(void *); if (!scratches) return NULL;ipcomp_scratches does not know about this allocation failure.Therefore holding the old obsolete address. ...}So when we free,static void ipcomp_free_scratches(void){ ... scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));Trying to free non existent page, causing warning: trying to vfreeexistent vm area. ...}Fix this breakage by updating ipcomp_scrtches with NULL when scratchesis freed
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libopenssl1_1 < 1.1.1d-2.113.1 (version in image is 1.1.1d-2.98.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: do not accept ACK of bytes we never sentThis patch is based on a detailed report and ideas from Yepeng Panand Christian Rossow.ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.This can be refined for new (and possibly spoofed) flows,by not accepting ACK for bytes that were never sent.This greatly improves TCP security at a little cost.I added a Fixes: tag to make sure this patch will reach stable trees,even if the 'blamed' patch was adhering to the RFC.tp->bytes_acked was added in linux-4.2Following packetdrill test (courtesy of Yepeng Pan) showsthe issue at hand:0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0+0 bind(3, ..., ...) = 0+0 listen(3, 1024) = 0// ---------------- Handshake ------------------- //// when window scale is set to 14 the window size can be extended to// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)// ,though this ack number acknowledges some data never// sent by the server.+0 < S 0:0(0) win 65535 +0 > S. 0:0(0) ack 1 <...>+0 < . 1:1(0) ack 1 win 65535+0 accept(3, ..., ...) = 4// For the established connection, we send an ACK packet,// the ack packet uses ack number 1 - 1073725300 + 2^32,// where 2^32 is used to wrap around.// Note: we used 1073725300 instead of 1073725440 to avoid possible// edge cases.// 1 - 1073725300 + 2^32 = 3221241997// Oops, old kernels happily accept this packet.+0 < . 1:1001(1000) ack 3221241997 win 65535// After the kernel fix the following will be replaced by a challenge ACK,// and prior malicious frame would be dropped.+0 > . 1:1(0) ack 1001
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: Issue summary: A timing side-channel which could potentially allow recoveringthe private key exists in the ECDSA signature computation.Impact summary: A timing side-channel in ECDSA signature computationscould allow recovering the private key by an attacker. However, measuringthe timing would require either local access to the signing application ora very fast network connection with low latency.There is a timing signal of around 300 nanoseconds when the top word ofthe inverted ECDSA nonce value is zero. This can happen with significantprobability only for some of the supported elliptic curves. In particularthe NIST P-521 curve is affected. To be able to measure this leak, the attackerprocess must either be located in the same physical computer or musthave a very fast network connection with low latency. For that reasonthe severity of this vulnerability is Low.The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libopenssl1_1 < 1.1.1d-2.116.1 (version in image is 1.1.1d-2.98.1).
-
Description: A timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libgcrypt20 < 1.6.1-16.86.1 (version in image is 1.6.1-16.83.1).
-
Description: Issue summary: Some non-default TLS server configurations can cause unboundedmemory growth when processing TLSv1.3 sessionsImpact summary: An attacker may exploit certain server configurations to triggerunbounded memory growth that would lead to a Denial of ServiceThis problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option isbeing used (but not if early_data support is also configured and the defaultanti-replay protection is in use). In this case, under certain conditions, thesession cache can get into an incorrect state and it will fail to flush properlyas it fills. The session cache will continue to grow in an unbounded manner. Amalicious client could deliberately create the scenario for this failure toforce a Denial of Service. It may also happen by accident in normal operation.This issue only affects TLS servers supporting TLSv1.3. It does not affect TLSclients.The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL1.0.2 is also not affected by this issue.
Packages affected:
- libopenssl1_1 < 1.1.1d-2.110.2 (version in image is 1.1.1d-2.98.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: make sure init the accept_queue's spinlocks onceWhen I run syz's reproduction C program locally, it causes the followingissue:pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c730 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fffR10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0Call Trace: _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20The issue triggering process is analyzed as follows:Thread A Thread Btcp_v4_rcv //receive ack TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV socketsTCP_SYN_RECV state is really special, it is only used bycross-syn connections, mostly used by fuzzers.In the following crash [1], syzbot managed to trigger a divideby zero in tcp_rcv_space_adjust()A socket makes the following state transitions,without ever calling tcp_init_transfer(),meaning tcp_init_buffer_space() is also not called. TCP_CLOSEconnect() TCP_SYN_SENT TCP_SYN_RECVshutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1To fix this issue, change tcp_shutdown() to notperform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,which makes no sense anyway.When tcp_rcv_state_process() later changes socket statefrom TCP_SYN_RECV to TCP_ESTABLISH, then look atsk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,and send a FIN packet from a sane socket state.This means tcp_send_fin() can now be called from BHcontext, and must use GFP_ATOMIC allocations.[1]divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2daFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0Call Trace: tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7faeb6363db9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012bRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001cR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-requests > 0-0 (version in image is 2.24.0-8.14.1).
-
Description: REXML is an XML toolkit for Ruby. The REXML gem before 3.3.9 has a ReDoS vulnerability when it parses an XML that has many digits between &# and x...; in a hex numeric character reference (&#x...;). This does not happen with Ruby 3.2 or later. Ruby 3.1 is the only affected maintained Ruby. The REXML gem 3.3.9 or later include the patch to fix the vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.
Packages affected:
- expat > 0-0 (version in image is 2.1.0-21.28.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a "no overlap"response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.
Packages affected:
- libopenssl1_0_0 < 1.0.2p-3.95.1 (version in image is 1.0.2p-3.84.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 socketsWhen calling netlbl_conn_setattr(), addr->sa_family is usedto determine the function behavior. If sk is an IPv4 socket,but the connect function is called with an IPv6 address,the function calipso_sock_setattr() is triggered.Inside this function, the following code is executed:sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;Since sk is an IPv4 socket, pinet6 is NULL, leading to anull pointer dereference.This patch fixes the issue by checking if inet6_sk(sk)returns a NULL pointer before accessing pinet6.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- krb5 > 0-0 (version in image is 1.12.5-40.52.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: don't restore null sk_state_changequeue->state_change is set as part of nvmet_tcp_set_queue_sock(), but ifthe TCP connection isn't established when nvmet_tcp_set_queue_sock() iscalled then queue->state_change isn't set and sock->sk->sk_state_changeisn't replaced.As such we don't need to restore sock->sk->sk_state_change ifqueue->state_change is NULL.This avoids NULL pointer dereferences such as this:[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 286.467147][ C0] RIP: 0010:0x0[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400[ 286.475453][ C0] Call Trace:[ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60[ 286.478174][ C0] ? __build_skb_around+0x234/0x330[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30[ 286.482769][ C0] ? ktime_get+0x66/0x150[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10[ 286.486917][ C0] ? lock_release+0x217/0x2c0[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack][ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420[ 286.494268][ C0] ip_local_deliver+0x168/0x430[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20[ 286.496806][ C0] ? lock_release+0x217/0x2c0[ 286.497414][ C0] ip_rcv+0x455/0x6e0[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10[ ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a client that connects to cupsd but sends slow messages, e.g. only one byte per second, delays cupsd as a whole, such that it becomes unusable by other clients. This issue has been patched in version 2.4.15.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- cups-libs > 0-0 (version in image is 1.7.5-20.46.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- gpg2 > 0-0 (version in image is 2.0.24-9.14.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix UBSAN shift-out-of-bounds warningIf get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end updoing a shift operation where the number of bits shifted equalsnumber of bits in the operand. This behaviour is undefined.Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if thecount is >= number of bits in the operand.Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp: fix race between close() and udp_abort()Kaustubh reported and diagnosed a panic in udp_lib_lookup().The root cause is udp_abort() racing with close(). Bothracing functions acquire the socket lock, but udp{v6}_destroy_sock()release it before performing destructive actions.We can't easily extend the socket lock scope to avoid the race,instead use the SOCK_DEAD flag to prevent udp_abort from doingany action when the critical race happens.Diagnosed-and-tested-by: Kaustubh Pandey
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: fix possible use-after-free in HFC_cleanup()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mcb: fix error handling in mcb_alloc_bus()There are two bugs:1) If ida_simple_get() fails then this code calls put_device(carrier) but we haven't yet called get_device(carrier) and probably that leads to a use after free.2) After device_initialize() then we need to use put_device() to release the bus. This will free the internal resources tied to the device and call mcb_free_bus() which will free the rest.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix UAF in run_timer_softirq()When dm_resume() and dm_destroy() are concurrent, it willlead to UAF, as follows: BUG: KASAN: use-after-free in __run_timers+0x173/0x710 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 Call Trace: dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+0x16e/0x62c __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0One of the concurrency UAF can be shown as below: use freedo_resume | __find_device_hash_cell | dm_get | atomic_inc(&md->holders) | | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | atomic_read(&md->holders) | msleep(1) dm_resume | __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add delay work | dm_put | atomic_dec(&md->holders) | | dm_table_destroy | pool_dtr | __pool_dec | __pool_destroy | destroy_workqueue | kfree(pool) # free pool time out__do_softirq run_timer_softirq # pool has already been freedThis can be easily reproduced using: 1. create thin-pool 2. dmsetup suspend pool 3. dmsetup resume pool 4. dmsetup remove_all # Concurrent with 3The root cause of this UAF bug is that dm_resume() adds timer afterdm_destroy() skips cancelling the timer because of suspend status.After timeout, it will call run_timer_softirq(), however pool hasalready been freed. The concurrency UAF bug will happen.Therefore, cancelling timer again in __pool_destroy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-hidpp: Fix kernel crash on receiver USB disconnecthidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)races when it races with itself.hidpp_connect_event() primarily runs from a workqueue but it also runson probe() and if a "device-connected" packet is received by the hwwhen the thread running hidpp_connect_event() from probe() is waiting onthe hw, then a second thread running hidpp_connect_event() will bestarted from the workqueue.This opens the following races (note the below code is simplified):1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; }We can actually see this race hit in the dmesg in the abrt outputattached to rhbz#2227968:[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.Testing with extra logging added has shown that after this the 2 threadstake turn grabbing the hw access mutex (send_mutex) so they ping-pongthrough all the other TOCTOU cases managing to hit all of them:2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; }3. Initializing the power_supply class for the battery (problematic!):hidpp_initialize_battery(){ if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg);}4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev);The really big problem here is 3. Hitting the race leads to the followingsequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg);So now we have registered 2 power supplies for the same battery,which looks a bit weird from userspace's pov but this is not eventhe really big problem.Notice how:1. This is all devm-maganaged2. The hidpp->battery.desc struct is shared between the 2 power supplies3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup()This causes a use after free scenario on USB disconnect of the receiver:1. The last registered power supply class device gets unregistered2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one:Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08...Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_eventSep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0...Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680Sep 22 20:01:35 eric kernel: ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/MCE: Always save CS register on AMD Zen IF Poison errorsThe Instruction Fetch (IF) units on current AMD Zen-based systems do notguarantee a synchronous #MC is delivered for poison consumption errors.Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, themicroarchitecture does guarantee that the exception is delivered withinthe same context. In other words, the exact rIP is not known, but thecontext is known to not have changed.There is no architecturally-defined method to determine this behavior.The Code Segment (CS) register is always valid on such IF unit poisonerrors regardless of the value of MCG_STATUS[EIPV|RIPV].Add a quirk to save the CS register for poison consumption from the IFunit banks.This is needed to properly determine the context of the error.Otherwise, the severity grading function will assume the context isIN_KERNEL due to the m->cs value being 0 (the initialized value). Thisleads to unnecessary kernel panics on data poison errors due to thekernel believing the poison consumption occurred in kernel context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix race condition in hidp_session_threadThere is a potential race condition in hidp_session_thread that maylead to use-after-free. For instance, the timer is active whilehidp_del_timer is called in hidp_session_thread(). After hidp_session_put,then 'session' will be freed, causing kernel panic when hidp_idle_timeoutis running.The solution is to use del_timer_sync instead of del_timer.Here is the call trace:? hidp_session_probe+0x780/0x780call_timer_fn+0x2d/0x1e0__run_timers.part.0+0x569/0x940hidp_session_probe+0x780/0x780call_timer_fn+0x1e0/0x1e0ktime_get+0x5c/0xf0lapic_next_deadline+0x2c/0x40clockevents_program_event+0x205/0x320run_timer_softirq+0xa9/0x1b0__do_softirq+0x1b9/0x641__irq_exit_rcu+0xdc/0x190irq_exit_rcu+0xe/0x20sysvec_apic_timer_interrupt+0xa1/0xc0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: uclogic: Correct devm device reference for hidinput input_dev nameReference the HID device rather than the input device for the devmallocation of the input_dev name. Referencing the input_dev would lead to ause-after-free when the input_dev was unregistered and subsequently fires auevent that depends on the name. At the point of firing the uevent, thename would be freed by devres management.Use devm_kasprintf to simplify the logic for allocating memory andformatting the input_dev name string.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix potential user-after-freeThis fixes all instances of which requires to allocate a buffer callingalloc_skb which may release the chan lock and reacquire later whichmakes it possible that the chan is disconnected in the meantime.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Address KCSAN report on bpf_lru_listKCSAN reported a data-race when accessing node->ref.Although node->ref does not have to be accurate,take this chance to use a more common READ_ONCE() and WRITE_ONCE()pattern instead of data_race().There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().This patch also adds bpf_lru_node_clear_ref() to do theWRITE_ONCE(node->ref, 0) also.==================================================================BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elemwrite to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023==================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi->poll_ownernon atomically. The ->poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Prevent USB core invalid event buffer address accessThis commit addresses an issue where the USB core could access aninvalid event buffer address during runtime suspend, potentially causingSMMU faults and other memory issues in Exynos platforms. The problemarises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.To prevent this hardware quirk on Exynos platforms, this commit ensuresthat the event buffer address is not cleared by software when the USBcore is active during runtime suspend by checking its status beforeclearing the buffer address.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Protect mgmt_pending list with its own lockThis uses a mutex to protect from concurrent access of mgmt_pendinglist which can cause crashes like:==================================================================BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check return result of sb_min_blocksizeSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.Syzkaller forks multiple processes which after mounting the Squashfsfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in theprocess of mounting a Squashfs filesystem on /dev/loop0, the failureoccurs. When this happens the following code in squashfs_fill_super()fails.----msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);msblk->devblksize_log2 = ffz(~msblk->devblksize);----sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2is set to 64.This subsequently causes theUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36shift exponent 64 is too large for 64-bit type 'u64' (aka'unsigned long long')This commit adds a check for a 0 return by sb_min_blocksize().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_conn_close().syzbot reported a null-ptr-deref in tipc_conn_close() during netnsdismantle. [0]tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and callstipc_conn_close() for each tipc_conn.The problem is that tipc_conn_close() is called after releasing theIDR lock.At the same time, there might be tipc_conn_recv_work() running and itcould call tipc_conn_close() for the same tipc_conn and release itslast ->kref.Once we release the IDR lock in tipc_topsrv_stop(), there is noguarantee that the tipc_conn is alive.Let's hold the ref before releasing the lock and put the ref aftertipc_conn_close() in tipc_topsrv_stop().[0]:BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00)The buggy address belongs to the page:page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0flags: 0xfff00000000100(slab)raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent NULL pointer dereference in UTF16 conversionThere can be a NULL pointer dereference bug here. NULL is passed to__cifs_sfu_make_node without checks, which passes it unchecked tocifs_strndup_to_utf16, which in turn passes it tocifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 andreturns NULL early to prevent dereferencing NULL pointer.Found by Linux Verification Center (linuxtesting.org) with SVACE
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike "sg_write_same --ndob" we will crash in target_core_iblock/file'sexecute_write_same handlers when we go to access the se_cmd->t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don't support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: Closing of an event channel in the Linux kernel can result in a deadlock.This happens when the close is being performed in parallel to an unrelatedXen console action and the handling of a Xen console interrupt in anunprivileged guest.The closing of an event channel is e.g. triggered by removal of aparavirtual device on the other side. As this action will cause consolemessages to be issued on the other side quite often, the chance oftriggering the deadlock is not neglectable.Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernelon Arm doesn't use queued-RW-locks, which are required to trigger theissue (on Arm32 a waiting writer doesn't block further readers to getthe lock).
Packages affected:
- kernel-default < 4.12.14-122.183.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: assert requested protocol is validThe protocol is used in a bit mask to determine if the protocol issupported. Assert the provided protocol is less than the maximumdefined so it doesn't potentially perform a shift-out-of-bounds andprovide a clearer error for undefined protocols vs unsupported ones.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: enable proper endpoint verificationSyzkaller reports [1] hitting a warning about an endpoint in usenot having an expected type to it.Fix the issue by checking for the existence of all properendpoints with their according types intact.Sadly, this patch has not been tested on real hardware.[1] Syzkaller report:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504...Call Trace: ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbmod: Skip non-Ethernet packetsCurrently tcf_skbmod_act() assumes that packets use Ethernet as their L2protocol, which is not always the case. As an example, for CAN devices: $ ip link add dev vcan0 type vcan $ ip link set up vcan0 $ tc qdisc add dev vcan0 root handle 1: htb $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \ matchall action skbmod swap macDoing the above silently corrupts all the packets. Do not perform skbmodactions for non-Ethernet packets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/srso: Add SRSO mitigation for Hygon processorsAdd mitigation for the speculative return stack overflow vulnerabilitywhich exists on Hygon processors too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.65.1).
-
Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix off-by-one issues in iavf_config_rss_reg()There are off-by-one bugs when configuring RSS hash key and lookuptable, causing out-of-bounds reads to memory [1] and out-of-boundswrites to device registers.Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4where `rss_{key,lut}_size / 4` is the number of dwords, so the lastvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`accesses one element past the end.Fix the issues by using `<` instead of `<=`, ensuring we do not exceedthe bounds.[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63 CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, mishandles NULL files in a .debug_line file table, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ELF file, related to concat_filename. NOTE: this issue is caused by an incomplete fix for CVE-2017-15023.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The elf_parse_notes function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (out-of-bounds read and segmentation violation) via a note with a large alignment.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
Packages affected:
- openssl > 0-0 (version in image is 1.0.2p-1.13).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: fix out-of-bounds memory accessesThere are two array out-of-bounds memory accesses, one incipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk(). Botherrors are embarassingly simple, and the fixes are straightforward.As a FYI for anyone backporting this patch to kernels prior to v4.8,you'll want to apply the netlbl_bitmap_walk() patch tocipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist beforeLinux v4.8.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ contextIf a driver calls can_get_echo_skb() during a hardware IRQ (which is often, butnot always, the case), the 'WARN_ON(in_irq)' innet/core/skbuff.c#skb_release_head_state() might be triggered, under networkcongestion circumstances, together with the potential risk of a NULL pointerdereference.The root cause of this issue is the call to kfree_skb() instead ofdev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().This patch prevents the skb to be freed within the call to netif_rx() byincrementing its reference count with skb_get(). The skb is finally freed byone of the in-irq-context safe functions: dev_consume_skb_any() ordev_kfree_skb_any(). The "any" version is used because some drivers might callcan_get_echo_skb() in a normal context.The reason for this issue to occur is that initially, in the core networkstack, loopback skb were not supposed to be received in hardware IRQ context.The CAN stack is an exeption.This bug was previously reported back in 2017 in [1] but the proposed patchnever got accepted.While [1] directly modifies net/core/dev.c, we try to propose here asmoother modification local to CAN network stack (the assumptionbehind is that only CAN devices are affected by this issue).[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in s390 eBPF JIT in bpf_jit_insn in arch/s390/net/bpf_jit_comp.c in the Linux kernel. In this flaw, a local attacker with special user privilege can circumvent the verifier and may lead to a confidentiality problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: Integer Overflow or Wraparound vulnerability in openEuler kernel on Linux (filesystem modules) allows Forced Integer Overflow.This issue affects openEuler kernel: from 4.19.90 before 4.19.90-2401.3, from 5.10.0-60.18.0 before 5.10.0-183.0.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: hso_free_net_device in drivers/net/usb/hso.c in the Linux kernel through 5.13.4 calls unregister_netdev without checking for the NETREG_REGISTERED state, leading to a use-after-free and a double free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in the Linux kernel's EBPF verifier when handling internal data structures. Internal memory locations could be returned to userspace. A local attacker with the permissions to insert eBPF code to the kernel can use this to leak internal kernel memory details defeating some of the exploit mitigations in place for the kernel.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hso: fix null-ptr-deref during tty device unregistrationMultiple ttys try to claim the same the minor number causing a doubleunregistration of the same device. The first unregistration succeedsbut the next one results in a null-ptr-deref.The get_free_serial_index() function returns an available minor numberbut doesn't assign it immediately. The assignment is done by the callerlater. But before this assignment, calls to get_free_serial_index()would return the same minor number.Fix this by modifying get_free_serial_index to assign the minor numberimmediately after one is found to be and rename it to obtain_minor()to better reflect what it does. Similary, rename set_serial_by_index()to release_minor() and modify it to free up the minor number of thegiven hso_serial. Every obtain_minor() should have correspondingrelease_minor() call.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: fix info leak in hid_submit_ctrlIn hid_submit_ctrl(), the way of calculating the report length doesn'ttake into account that report->size can be zero. When running thesyzkaller reproducer, a report of size 0 causes hid_submit_ctrl) tocalculate transfer_buffer_length as 16384. When this urb is passed tothe usb core layer, KMSAN reports an info leak of 16384 bytes.To fix this, first modify hid_report_len() to account for the zeroreport size case by using DIV_ROUND_UP for the division. Then, call itfrom hid_submit_ctrl().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_limit: avoid possible divide error in nft_limit_initdiv_u64() divides u64 by u32.nft_limit_init() wants to divide u64 by u64, use the appropriatemath function (div64_u64)divide error: 0000 [#1] PREEMPT SMP KASANCPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline]RIP: 0010:div_u64 include/linux/math64.h:127 [inline]RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00RSP: 0018:ffffc90009447198 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003RBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline] nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix use-after-free in tw_timer_handlerA real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20This issue was also reported since 2017 in the thread [1],unfortunately, the issue was still can be reproduced after fixingDCCP.The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a netnamespace is destroyed since tcp_sk_ops is registered befroreipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_opsin the list of pernet_list. There will be a use-after-free onnet->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_netif there are some inflight time-wait timers.This bug is not introduced by commit f2bf415cfed7 ("mib: add net toNET_ADD_STATS_BH") since the net_statistics is a global variableinstead of dynamic allocation and freeing. Actually, commit61a7e26028b9 ("mib: put net statistics on struct net") introducesthe bug since it put net statistics on struct net and free it whennet namespace is destroyed.Moving init_ipv4_mibs() to the front of tcp_init() to fix this bugand replace pr_crit() with panic() since continuing is meaninglesswhen init_ipv4_mibs() fails.[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Restructure trace_clock_global() to never blockIt was reported that a fix to the ring buffer recursion detection wouldcause a hung machine when performing suspend / resume testing. Thefollowing backtrace was extracted from debugging that case:Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0With the following RIP:RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200Since the fix to the recursion detection would allow a single recursion tohappen while tracing, this lead to the trace_clock_global() taking a spinlock and then trying to take it again:ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */Tracing should *never* block, as it can lead to strange lockups like theabove.Restructure the trace_clock_global() code to instead of simply taking alock to update the recorded "prev_time" simply use it, as two eventshappening on two different CPUs that calls this at the same time, reallydoesn't matter which one goes first. Use a trylock to grab the lock forupdating the prev_time, and if it fails, simply try again the next time.If it failed to be taken, that means something else is already updatingit.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Do core softreset when switch modeAccording to the programming guide, to switch mode for DRD controller,the driver needs to do the following.To switch from device to host:1. Reset controller with GCTL.CoreSoftReset2. Set GCTL.PrtCapDir(host mode)3. Reset the host with USBCMD.HCRESET4. Then follow up with the initializing host registers sequenceTo switch from host to device:1. Reset controller with GCTL.CoreSoftReset2. Set GCTL.PrtCapDir(device mode)3. Reset the device with DCTL.CSftRst4. Then follow up with the initializing registers sequenceCurrently we're missing step 1) to do GCTL.CoreSoftReset and step 3) ofswitching from host to device. John Stult reported a lockup issue seenwith HiKey960 platform without these steps[1]. Similar issue is observedwith Ferry's testing platform[2].So, apply the required steps along with some fixes to Yu Chen's and JohnStultz's version. The main fixes to their versions are the missing waitfor clocks synchronization before clearing GCTL.CoreSoftReset and onlyapply DCTL.CSftRst when switching from host to device.[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failureWhen failing the driver probe because of invalid firmware properties,the GTDT driver unmaps the interrupt that it mapped earlier.However, it never checks whether the mapping of the interrupt actiallysucceeded. Even more, should the firmware report an illegal interruptnumber that overlaps with the GIC SGI range, this can result in anIPI being unmapped, and subsequent fireworks (as reported by DannFrazier).Rework the driver to have a slightly saner behaviour and actuallycheck whether the interrupt has been mapped before unmapping things.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between transaction aborts and fsyncs leading to use-after-freeThere is a race between a task aborting a transaction during a commit,a task doing an fsync and the transaction kthread, which leads to anuse-after-free of the log root tree. When this happens, it results in astack trace like the following: BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x139/0xa40 Code: c0 74 19 (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (...) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...) ---[ end trace ee2f1b19327d791d ]---The steps that lead to this crash are the following:1) We are at transaction N;2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync;3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree into a local variable named 'log_root_tree' at the top of btrfs_sync_log(). Task B is about to call write_all_supers(), but before that...4) Task A calls btrfs_commit_transaction(), and after it sets the transaction state to TRANS_STATE_COMMIT_START, an error happens before it w---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0 blk_mq_request_issue_directly+0x4e/0xb0Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is nowallocated by upper layers. This fixes smatch warning of srb unintendedfree.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: Fix NULL pointer in flush_workqueueOpen /dev/nbdX first, the config_refs will be 1 andthe pointers in nbd_device are still null. Disconnect/dev/nbdX, then reference a null recv_workq. Theprotection by config_refs in nbd_genl_disconnect is useless.[ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020[ 656.368943] #PF: supervisor write access in kernel mode[ 656.369844] #PF: error_code(0x0002) - not-present page[ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0[ 656.371693] Oops: 0002 [#1] SMP[ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1[ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014[ 656.375904] RIP: 0010:mutex_lock+0x29/0x60[ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d[ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246[ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020[ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318[ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40[ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00[ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000[ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0[ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 656.384927] Call Trace:[ 656.385111] flush_workqueue+0x92/0x6c0[ 656.385395] nbd_disconnect_and_put+0x81/0xd0[ 656.385716] nbd_genl_disconnect+0x125/0x2a0[ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0[ 656.386422] genl_rcv_msg+0xfc/0x2b0[ 656.386685] ? nbd_ioctl+0x490/0x490[ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0[ 656.387354] netlink_rcv_skb+0x62/0x180[ 656.387638] genl_rcv+0x34/0x60[ 656.387874] netlink_unicast+0x26d/0x590[ 656.388162] netlink_sendmsg+0x398/0x6c0[ 656.388451] ? netlink_rcv_skb+0x180/0x180[ 656.388750] ____sys_sendmsg+0x1da/0x320[ 656.389038] ? ____sys_recvmsg+0x130/0x220[ 656.389334] ___sys_sendmsg+0x8e/0xf0[ 656.389605] ? ___sys_recvmsg+0xa2/0xf0[ 656.389889] ? handle_mm_fault+0x1671/0x21d0[ 656.390201] __sys_sendmsg+0x6d/0xe0[ 656.390464] __x64_sys_sendmsg+0x23/0x30[ 656.390751] do_syscall_64+0x45/0x70[ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kyber: fix out of bounds access when preempted__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU andpasses the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctxfor the current CPU again and uses that to get the corresponding Kybercontext in the passed hctx. However, the thread may be preempted betweenthe two calls to blk_mq_get_ctx(), and the ctx returned the second timemay no longer correspond to the passed hctx. This "works" accidentallymost of the time, but it can cause us to read garbage if the second ctxcame from an hctx with more ctx's than the first one (i.e., ifctx->index_hw[hctx->type] > hctx->nr_ctx).This manifested as this UBSAN array index out of bounds error reportedby Jakub:UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9index 13106 is out of range for type 'long unsigned int [128]'Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30Only Kyber uses the hctx, so fix it by passing the request_queue to->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber canmap the queues itself to avoid the mismatch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock when cloning inline extents and using qgroupsThere are a few exceptional cases where cloning an inline extent needs tocopy the inline extent data into a page of the destination inode.When this happens, we end up starting a transaction while having a dirtypage for the destination inode and while having the range locked in thedestination's inode iotree too. Because when reserving metadata spacefor a transaction we may need to flush existing delalloc in case there isnot enough free space, we have a mechanism in place to prevent a deadlock,which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock whencloning inline extent and low on free metadata space").However when using qgroups, a transaction also reserves metadata qgroupspace, which can also result in flushing delalloc in case there is notenough available space at the moment. When this happens we deadlock, sinceflushing delalloc requires locking the file range in the inode's iotreeand the range was already locked at the very beginning of the cloneoperation, before attempting to start the transaction.When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extent_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747.556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] process_one_work+0x1aa/0x340 [72747.556426] worker_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964] __schedule+0x296/0x760 [72747.566968] ? finish_wait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extent_writepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] process_one_work+0x1aa/0x340 [72747.567202] worker_thread+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] task:fsstress state:D stack: ---truncated---
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: release page in error path to avoid BUG_ONConsider the following sequence of events:1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated.2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte().3. Meanwhile, let's say another process filled up the tmpfs being used.4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page.This triggers a BUG_ON in our caller, which asserts that the pageshould always be consumed, unless -ENOENT is returned.To fix this, detect if we have such a "dangling" page when accountingfails, and if so, release it before returning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s: Fix crashes when toggling entry flush barrierThe entry flush mitigation can be enabled/disabled at runtime via adebugfs file (entry_flush), which causes the kernel to patch itself toenable/disable the relevant mitigations.However depending on which mitigation we're using, it may not be safe todo that patching while other CPUs are active. For example the followingcrash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20Shows that we returned to userspace with a corrupted LR that points intothe kernel, due to executing the partially patched call to the fallbackentry flush (ie. we missed the LR restore).Fix it by doing the patching under stop machine. The CPUs that aren'tdoing the patching will be spinning in the core of the stop machinelogic. That is currently sufficient for our purposes, because none ofthe patching we do is to that code or anywhere in the vicinity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix use-after-free in i40e_client_subtask()Currently the call to i40e_client_del_instance frees the objectpf->cinst, however pf->cinst->lan_info is being accessed afterthe free. Fix this by adding the missing return.Addresses-Coverity: ("Read from pointer after free")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hookThe commit 1879445dfa7b ("perf/core: Set event's default::overflow_handler()") set a default event->overflow_handler inperf_event_alloc(), and replace the check event->overflow_handler withis_default_overflow_handler(), but one is missing.Currently, the bp->overflow_handler can not be NULL. As a result,enable_single_step() is always not invoked.Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_sendIn emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).If some error happens in emac_tx_fill_tpd(), the skb will be freed viadev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,thus my patch assigns skb->len to 'len' before the possible free anduse 'len' instead of skb->len later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix RX consumer index logic in the error path.In bnxt_rx_pkt(), the RX buffers are expected to complete in order.If the RX consumer index indicates an out of order buffer completion,it means we are hitting a hardware bug and the driver will abort allremaining RX packets and reset the RX ring. The RX consumer indexthat we pass to bnxt_discard_rx() is not correct. We should bepassing the current index (tmp_raw_cons) instead of the old index(raw_cons). This bug can cause us to be at the wrong index whentrying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()It is possible to call lpfc_issue_els_plogi() passing a did for which nomatching ndlp is found. A call is then made to lpfc_prep_els_iocb() with anull pointer to a lpfc_nodelist structure resulting in a null pointerdereference.Fix by returning an error status if no valid ndlp is found. Fix up commentsregarding ndlp reference counting.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Use after free in __vmbus_open()The "open_info" variable is added to the &vmbus_connection.chn_msg_list,but the error handling frees "open_info" without removing it from thelist. This will result in a use after free. First remove it from thelist, and then free it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_initADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however thevf2pf_lock is initialized in adf_dev_init(), which can fail and when itfail, the vf2pf_lock is either not initialized or destroyed, a subsequentuse of vf2pf_lock will cause issue.To fix this issue, only set this flag if adf_dev_init() returns 0.[ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0[ 7.180345] Call Trace:[ 7.182576] mutex_lock+0xc9/0xd0[ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat][ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat][ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat][ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Fix another memory leak in error handling pathsMemory allocated by 'vmbus_alloc_ring()' at the beginning of the probefunction is never freed in the error handling path.Add the missing 'vmbus_free_ring()' call.Note that it is already freed in the .remove function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Fix a memory leak in error handling pathsIf 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not beupdated and 'hv_uio_cleanup()' in the error handling path will not beable to free the corresponding buffer.In such a case, we need to free the buffer explicitly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbiosinit_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systemswhere the Dell WMI interface is supported. While exit_dell_smbios_wmi()unregisters it unconditionally, this leads to the following oops:[ 175.722921] ------------[ cut here ]------------[ 175.722925] Unexpected driver unregister![ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40...[ 175.723089] Call Trace:[ 175.723094] cleanup_module+0x5/0xedd [dell_smbios]...[ 175.723148] ---[ end trace 064c34e1ad49509d ]---Make the unregister happen on the same condition the register happensto fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Return CQE error if invalid lkey was suppliedRXE is missing update of WQE status in LOCAL_WRITE failures. This causedthe following kernel panic if someone sent an atomic operation with anexplicitly wrong lkey.[leonro@vm ~]$ mkt testtest_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Add pointer checks in qedf_update_link_speed()The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] [ 14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250] __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257] common_interrupt+0xf/0xf [ 14.042259] API qedf_link_update() is getting called from QED but by that timeshost_data is not initialised. This results in a NULL pointer dereferencewhen we try to dereference shost_data while updating supported_speeds.Add a NULL pointer check before dereferencing shost_data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()The wrong goto label was used for the error case and missed cleanup of thepkt allocation.Addresses-Coverity-ID: 1493352 ("Resource leak")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kvm: Disable kvmclock on all CPUs on shutdownCurrenly, we disable kvmclock from machine_shutdown() hook and thisonly happens for boot CPU. We need to disable it for all CPUs toguard against memory corruption e.g. on restore from hibernate.Note, writing '0' to kvmclock MSR doesn't clear memory location, itjust prevents hypervisor from updating the location so for the shortwhile after write and while CPU is still alive, the clock remains usableand correct so we don't need to switch to some other clocksource.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: abort in rename_exchange if we fail to insert the second refError injection stress uncovered a problem where we'd leave a danglinginode ref if we failed during a rename_exchange. This happens becausewe insert the inode ref for one side of the rename, and then for theother side. If this second inode ref insert fails we'll leave the firstone dangling and leave a corrupt file system behind. Fix this byaborting if we did the insert for the first inode ref.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix data corruption by fallocateWhen fallocate punches holes out of inode size, if original isize is inthe middle of last cluster, then the part from isize to the end of thecluster will be zeroed with buffer write, at that time isize is not yetupdated to match the new size, if writeback is kicked in, it will invokeocfs2_writepage()->block_write_full_page() where the pages out of inodesize will be dropped. That will cause file corruption. Fix this byzero out eof blocks when extending the inode size.Running the following command with qemu-image 4.2.1 can get a corruptedcoverted image file easily. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.convThe usage of fallocate in qemu is like this, it first punches holes outof inode size, then extend the inode size. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.htmlv2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failedWe got follow bug_on when run fsstress with injecting IO fault:[130747.323114] kernel BUG at fs/ext4/extents_status.c:762![130747.323117] Internal error: Oops - BUG: 0 [#1] SMP......[130747.334329] Call trace:[130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4][130747.334975] ext4_cache_extents+0x64/0xe8 [ext4][130747.335368] ext4_find_extent+0x300/0x330 [ext4][130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4][130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4][130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4][130747.336995] ext4_readpage+0x54/0x100 [ext4][130747.337359] generic_file_buffered_read+0x410/0xae8[130747.337767] generic_file_read_iter+0x114/0x190[130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4][130747.338556] __vfs_read+0x11c/0x188[130747.338851] vfs_read+0x94/0x150[130747.339110] ksys_read+0x74/0xf0This patch's modification is according to Jan Kara's suggestion in:https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/"I see. Now I understand your patch. Honestly, seeing how fragile is tryingto fix extent tree after split has failed in the middle, I would probablygo even further and make sure we fix the tree properly in case of ENOSPCand EDQUOT (those are easily user triggerable). Anything else indicates aHW problem or fs corruption so I'd rather leave the extent tree as is anddon't try to fix it (which also means we will not create overlappingextents)."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pid: take a reference when initializing `cad_pid`During boot, kernel_init_freeable() initializes `cad_pid` to the inittask's struct pid. Later on, we may change `cad_pid` via a sysctl, andwhen this happens proc_do_cad_pid() will increment the refcount on thenew pid via get_pid(), and will decrement the refcount on the old pidvia put_pid(). As we never called get_pid() when we initialized`cad_pid`, we decrement a reference we never incremented, can thereforefree the init task's struct pid early. As there can be danglingreferences to the struct pid, we can later encounter a use-after-free(e.g. when delivering signals).This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems tohave been around since the conversion of `cad_pid` to struct pid incommit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from thepre-KASAN stone age of v2.6.19.Fix this by getting a reference to the init task's struct pid when weassign it to `cad_pid`.Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix memory leak in ext4_fill_superBuffer head references must be released before calling kill_bdev();otherwise the buffer head (and its page referenced by b_data) will notbe freed by kill_bdev, and subsequently that bh will be leaked.If blocksizes differ, sb_set_blocksize() will kill current buffers andpage cache by using kill_bdev(). And then super block will be rereadagain but using correct blocksize this time. sb_set_blocksize() didn'tfully free superblock page and buffer head, and being busy, they werenot freed and instead leaked.This can easily be reproduced by calling an infinite loop of: systemctl start .mount, and systemctl stop .mount... since systemd creates a cgroup for each slice which it mounts, andthe bh leak get amplified by a dying memory cgroup that also nevergets freed, and memory consumption is much more easily noticed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: Add NULL pointer checks when freeing irqs.When freeing notification blocks, we index priv->msix_vectors.If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors)this could lead to a NULL pointer dereference if the driver is unloaded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix a use-after-freelooks like we forget to set ttm->sg to NULL.Hit panic below[ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI[ 1235.989074] Call Trace:[ 1235.991751] sg_free_table+0x17/0x20[ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu][ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu][ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm][ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm][ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm][ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm][ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu][ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu][ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu][ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: remove device from smcd_dev_list after failed device_add()If the device_add() for a smcd_dev fails, there's no cleanup step thatrolls back the earlier list_add(). The device subsequently gets freed,and we end up with a corrupted list.Add some error handling that removes the device from the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON in link_to_fixup_dirWhile doing error injection testing I got the following panic kernel BUG at fs/btrfs/tree-log.c:1862! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:link_to_fixup_dir+0xd5/0xe0 RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216 RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0 RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000 RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001 R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800 R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065 FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0 Call Trace: replay_one_buffer+0x409/0x470 ? btree_read_extent_buffer_pages+0xd0/0x110 walk_up_log_tree+0x157/0x1e0 walk_log_tree+0xa6/0x1d0 btrfs_recover_log_trees+0x1da/0x360 ? replay_one_extent+0x7b0/0x7b0 open_ctree+0x1486/0x1720 btrfs_mount_root.cold+0x12/0xea ? __kmalloc_track_caller+0x12f/0x240 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 ? vfs_parse_fs_string+0x4d/0x90 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 path_mount+0x433/0xa10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xaeWe can get -EIO or any number of legitimate errors frombtrfs_search_slot(), panicing here is not the appropriate response. Theerror path for this code handles errors properly, simply return theerror.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mld: fix panic in mld_newpack()mld_newpack() doesn't allow to allocate high order page,only order-0 allocation is allowed.If headroom size is too large, a kernel panic could occur in skb_put().Test commands: ip netns del A ip netns del B ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip link set veth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set veth0 up ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0 ip netns exec B ip link set lo up ip netns exec B ip link set veth1 up ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1 for i in {1..99} do let A=$i-1 ip netns exec A ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100 ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i ip netns exec A ip link set ip6gre$i up ip netns exec B ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100 ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i ip netns exec B ip link set ip6gre$i up doneSplat looks like:kernel BUG at net/core/skbuff.c:110!invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTICPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:skb_panic+0x15d/0x15fCode: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 8341 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 8934 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20RSP: 0018:ffff88810091f820 EFLAGS: 00010282RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efbRBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0FS: 0000000000000000(0000) GS:ffff888117c00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 skb_put.cold.104+0x22/0x22 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? rcu_read_lock_sched_held+0x91/0xc0 mld_newpack+0x398/0x8f0 ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600 ? lock_contended+0xc40/0xc40 add_grhead.isra.33+0x280/0x380 add_grec+0x5ca/0xff0 ? mld_sendpack+0xf40/0xf40 ? lock_downgrade+0x690/0x690 mld_send_initial_cr.part.34+0xb9/0x180 ipv6_mc_dad_complete+0x15d/0x1b0 addrconf_dad_completed+0x8d2/0xbb0 ? lock_downgrade+0x690/0x690 ? addrconf_rs_timer+0x660/0x660 ? addrconf_dad_work+0x73c/0x10e0 addrconf_dad_work+0x73c/0x10e0Allowing high order page allocation could fix this problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fujitsu: fix potential null-ptr-derefIn fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointerderef. To fix this, check the return value of ioremap and return -1to the caller in case of failure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: fix the potential memory leak in fec_enet_init()If the memory allocated for cbd_base is failed, it shouldfree the memory allocated for the queues, otherwise it causesmemory leak.And if the memory allocated for the queues is failed, it canreturn error directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: i801: Don't generate an interrupt on bus resetNow that the i2c-i801 driver supports interrupts, setting the KILL bitin a attempt to recover from a timed out transaction triggers aninterrupt. Unfortunately, the interrupt handler (i801_isr) is notprepared for this situation and will try to process the interrupt asif it was signaling the end of a successful transaction. In the caseof a block transaction, this can result in an out-of-range memoryaccess.This condition was reproduced several times by syzbot:https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34ehttps://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79ehttps://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610ehttps://syzkaller.appspot.com/bug?extid=33f6c360821c399d69ebhttps://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043ahttps://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79So disable interrupts while trying to reset the bus. Interrupts willbe enabled again for the following transaction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: fix a crash if ->get_sset_count() failsIf ds->ops->get_sset_count() fails then it "count" is a negative errorcode such as -EOPNOTSUPP. Because "i" is an unsigned int, the negativeerror code is type promoted to a very high value and the loop willcorrupt memory until the system crashes.Fix this by checking for error codes and changing the type of "i" tojust int.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: spi-fsl-dspi: Fix a resource leak in an error handling path'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in theerror handling path of the probe function, as already done in the removefunction
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: skb_linearize the head skb when reassembling msgsIt's not a good idea to append the frag skb to a skb's frag_list ifthe frag_list already has skbs from elsewhere, such as this skb wascreated by pskb_copy() where the frag_list was cloned (all the skbsin it were skb_get'ed) and shared by multiple skbs.However, the new appended frag skb should have been only seen by thecurrent skb. Otherwise, it will cause use after free crashes as thisappended frag skb are seen by multiple skbs but it only got skb_getcalled once.The same thing happens with a skb updated by pskb_may_pull() with askb_cloned skb. Li Shuang has reported quite a few crashes causedby this when doing testing over macvlan devices: [] kernel BUG at net/core/skbuff.c:1970! [] Call Trace: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] [] macvlan_process_broadcast+0x148/0x150 [macvlan] [] process_one_work+0x1a7/0x360 [] worker_thread+0x30/0x390 [] kernel BUG at mm/usercopy.c:102! [] Call Trace: [] __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 [] __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram_iter+0x3b/0x90 [] tipc_recvmsg+0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] kernel BUG at mm/slub.c:305! [] Call Trace: [] [] kmem_cache_free+0x3ff/0x400 [] __netif_receive_skb_core+0x12c/0xc40 [] ? kmem_cache_alloc+0x12e/0x270 [] netif_receive_skb_internal+0x3d/0xb0 [] ? get_rx_page_info+0x8e/0xa0 [be2net] [] be_poll+0x6ef/0xd00 [be2net] [] ? irq_exit+0x4f/0x100 [] net_rx_action+0x149/0x3b0 ...This patch is to fix it by linearizing the head skb if it has frag_listset in tipc_buf_append(). Note that we choose to do this before callingskb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we cannot just drop the frag_list either as the early time.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: wait and exit until all work queues are doneOn some host, a crash could be triggered simply by repeating thesecommands several times: # modprobe tipc # tipc bearer enable media udp name UDP1 localip 127.0.0.1 # rmmod tipc [] BUG: unable to handle kernel paging request at ffffffffc096bb00 [] Workqueue: events 0xffffffffc096bb00 [] Call Trace: [] ? process_one_work+0x1a7/0x360 [] ? worker_thread+0x30/0x390 [] ? create_worker+0x1a0/0x1a0 [] ? kthread+0x116/0x130 [] ? kthread_flush_work_fn+0x10/0x10 [] ? ret_from_fork+0x35/0x40When removing the TIPC module, the UDP tunnel sock will be delayed torelease in a work queue as sock_release() can't be done in rtnl_lock().If the work queue is schedule to run after the TIPC module is removed,kernel will crash as the work queue function cleanup_beareri() code nolonger exists when trying to invoke it.To fix it, this patch introduce a member wq_count in tipc_net to trackthe numbers of work queues in schedule, and wait and exit until allwork queues are done in tipc_exit_net().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: fix shutdown crash when component not probedWhen main component is not probed, by example when the dw-hdmi module isnot loaded yet or in probe defer, the following crash appears on shutdown:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038...pc : meson_drv_shutdown+0x24/0x50lr : platform_drv_shutdown+0x20/0x30...Call trace:meson_drv_shutdown+0x24/0x50platform_drv_shutdown+0x20/0x30device_shutdown+0x158/0x360kernel_restart_prepare+0x38/0x48kernel_restart+0x18/0x68__do_sys_reboot+0x224/0x250__arm64_sys_reboot+0x24/0x30...Simply check if the priv struct has been allocated before using it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce()The value of mirror->pg_bytes_written should only be updated after asuccessful attempt to flush out the requests on the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix an Oopsable condition in __nfs_pageio_add_request()Ensure that nfs_pageio_error_cleanup() resets the mirror array contents,so that the structure reflects the fact that it is now empty.Also change the test in nfs_pageio_do_add_request() to be more robust bychecking whether or not the list is empty rather than relying on thevalue of pg_count.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: fix an incorrect limit in filelayout_decode_layout()The "sizeof(struct nfs_fh)" is two bytes too large and could lead tomemory corruption. It should be NFS_MAXFHSIZE because that's the sizeof the ->data[] buffer.I reversed the size of the arguments to put the variable on the left.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if thefirmware don't exists, function just return without initializing portsof 'rp2_card'. But now the interrupt handler function has beenregistered, and when an interrupt comes, 'rp2_uart_interrupt' may accessthose ports then causing NULL pointer dereference or other bugs.Because the driver does some initialization work in 'rp2_fw_cb', inorder to make the driver ready to handle interrupts, 'request_firmware'should be used instead of asynchronous 'request_firmware_nowait'.This report reveals it:INFO: trying to register non-static key.the code is fine but needs lockdep annotation.turning off the locking correctness validator.CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f88b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 9090 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdeRAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243BUG: unable to handle kernel NULL pointer dereference at 0000000000000010PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:493Co---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: usbfs: Don't WARN about excessively large memory allocationsSyzbot found that the kernel generates a WARNing if the user tries tosubmit a bulk transfer through usbfs with a buffer that is way toolarge. This isn't a bug in the kernel; it's merely an invalid requestfrom the user and the usbfs code does handle it correctly.In theory the same thing can happen with async transfers, or with thepacket descriptor table for isochronous transfers.To prevent the MM subsystem from complaining about these badallocation requests, add the __GFP_NOWARN flag to the kmalloc callsfor these buffers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: fix memory leak in smsc75xx_bindSyzbot reported memory leak in smsc75xx_bind().The problem was is non-freed memory in case oferrors after memory allocation.backtrace: [] kmalloc include/linux/slab.h:556 [inline] [] kzalloc include/linux/slab.h:686 [inline] [] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc/uss720: fix memory leak in uss720_probeuss720_probe forgets to decrease the refcount of usbdev in uss720_probe.Fix this by decreasing the refcount of usbdev by usb_put_dev.BUG: memory leakunreferenced object 0xffff888101113800 (size 2048): comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................ backtrace: [] kmalloc include/linux/slab.h:554 [inline] [] kzalloc include/linux/slab.h:684 [inline] [] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582 [] hub_port_connect drivers/usb/core/hub.c:5129 [inline] [] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] [] port_event drivers/usb/core/hub.c:5509 [inline] [] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275 [] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421 [] kthread+0x178/0x1b0 kernel/kthread.c:292 [] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix sysfs leak in alloc_iommu()iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequenterrors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()Commit de144ff4234f changes _pnfs_return_layout() to callpnfs_mark_matching_lsegs_return() passing NULL as the structpnfs_layout_range argument. Unfortunately,pnfs_mark_matching_lsegs_return() doesn't check if we have a value herebefore dereferencing it, causing an oops.I'm able to hit this crash consistently when running connectathon basictests on NFS v4.1/v4.2 against Ontap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: fix memory leak in nci_allocate_devicenfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev.Fix this by freeing hci_dev in nci_free_device.BUG: memory leakunreferenced object 0xffff888111ea6800 (size 1024): comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline] [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline] [<000000004bc25d43>] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [inline] [<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132 [<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345 [<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [<000000000ce658ca>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<000000007067d05f>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914 [<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000359c965a>] device_add+0x5be/0xc30 drivers/base/core.c:3109 [<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<00000000d40d36f6>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: musb: tusb6010: check return value after calling platform_get_resource()It will cause null-ptr-deref if platform_get_resource() returns NULL,we need check the return value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix scsi_mode_sense() buffer length handlingSeveral problems exist with scsi_mode_sense() buffer length handling: 1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255. 2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.Fix these 2 problems by using put_unaligned_be16() to set the allocationlength field of MODE SENSE(10) CDB and by returning an error when len istoo small.Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,even if the device driver did not set sdev->use_10_for_ms. In case ofinvalid opcode error for MODE SENSE(10), access to mode pages larger than255 bytes are not retried using MODE SENSE(6). To avoid buffer lengthoverflows for the MODE_SENSE(10) case, check that len is smaller than 65535bytes.While at it, also fix the folowing: * Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation. * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix link down processing to address NULL pointer dereferenceIf an FC link down transition while PLOGIs are outstanding to fabric wellknown addresses, outstanding ABTS requests may result in a NULL pointerdereference. Driver unload requests may hang with repeated "2878" logmessages.The Link down processing results in ABTS requests for outstanding ELSrequests. The Abort WQEs are sent for the ELSs before the driver had setthe link state to down. Thus the driver is sending the Abort with theexpectation that an ABTS will be sent on the wire. The Abort request isstalled waiting for the link to come up. In some conditions the driver mayauto-complete the ELSs thus if the link does come up, the Abort completionsmay reference an invalid structure.Fix by ensuring that Abort set the flag to avoid link traffic if issued dueto conditions where the link failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix NULL ptr dereference on VSI filter syncRemove the reason of null pointer dereference in sync VSI filters.Added new I40E_VSI_RELEASING flag to signalize deleting and releasingof VSI resources to sync this thread with sync filters subtask.Without this patch it is possible to start update the VSI filter listafter VSI is removed, that's causing a kernel oops.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: tty_buffer: Fix the softlockup issue in flush_to_ldiscWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120In the testcase pty04, The first process call the write syscall to senddata to the pty master. At the same time, the workqueue will do theflush_to_ldisc to pop data in a loop until there is no more data left.When the sender and workqueue running in different core, the sender sendsdata fastly in full time which will result in workqueue doing work in loopfor a long time and occuring softlockup in flush_to_ldisc with kernelconfigured without preempt. So I add need_resched check and cond_reschedin the flush_to_ldisc loop to avoid it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Improve SCSI abort handlingThe following has been observed on a test setup:WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65cCall trace: ufshcd_queuecommand+0x468/0x65c scsi_send_eh_cmnd+0x224/0x6a0 scsi_eh_test_devices+0x248/0x418 scsi_eh_ready_devs+0xc34/0xe58 scsi_error_handler+0x204/0x80c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30That warning is triggered by the following statement: WARN_ON(lrbp->cmd);Fix this warning by clearing lrbp->cmd from the abort handler.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix memory ordering between normal and ordered work functionsOrdered work functions aren't guaranteed to be handled by the same threadwhich executed the normal work functions. The only way execution betweennormal/ordered functions is synchronized is via the WORK_DONE_BIT,unfortunately the used bitops don't guarantee any ordering whatsoever.This manifested as seemingly inexplicable crashes on ARM64, whereasync_chunk::inode is seen as non-null in async_cow_submit which causessubmit_compressed_extents to be called and crash occurs becauseasync_chunk::inode suddenly became NULL. The call trace was similar to: pc : submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0 run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18Fix this by adding respective barrier calls which ensure that allaccesses preceding setting of WORK_DONE_BIT are strictly ordered beforesetting the flag. At the same time add a read barrier after reading ofWORK_DONE_BIT in run_ordered_work which ensures all subsequent loadswould be strictly ordered after reading the bit. This in turn ensuresare all accesses before WORK_DONE_BIT are going to be strictly orderedbefore any access that can occur in ordered_func.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()The following warning was observed running syzkaller:[ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;[ 3813.830724] program syz-executor not setting count and/or reply_len properly[ 3813.836956] ==================================================================[ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0[ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549[ 3813.846612] Call Trace:[ 3813.846995] dump_stack+0x108/0x15f[ 3813.847524] print_address_description+0xa5/0x372[ 3813.848243] kasan_report.cold+0x236/0x2a8[ 3813.849439] check_memory_region+0x240/0x270[ 3813.850094] memcpy+0x30/0x80[ 3813.850553] sg_copy_buffer+0x157/0x1e0[ 3813.853032] sg_copy_from_buffer+0x13/0x20[ 3813.853660] fill_from_dev_buffer+0x135/0x370[ 3813.854329] resp_readcap16+0x1ac/0x280[ 3813.856917] schedule_resp+0x41f/0x1630[ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0[ 3813.862699] scsi_dispatch_cmd+0x330/0x950[ 3813.863329] scsi_request_fn+0xd8e/0x1710[ 3813.863946] __blk_run_queue+0x10b/0x230[ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400[ 3813.865220] sg_common_write.isra.0+0xe61/0x2420[ 3813.871637] sg_write+0x6c8/0xef0[ 3813.878853] __vfs_write+0xe4/0x800[ 3813.883487] vfs_write+0x17b/0x530[ 3813.884008] ksys_write+0x103/0x270[ 3813.886268] __x64_sys_write+0x77/0xc0[ 3813.886841] do_syscall_64+0x106/0x360[ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9This issue can be reproduced with the following syzkaller log:r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0)r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00')open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782)write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)In resp_readcap16() we get "int alloc_len" value -1104926854, and then passthe huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. Thisleads to OOB in sg_copy_buffer().To solve this issue, define alloc_len as u32.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Fix memory leak during rmmodDriver failed to release all memory allocated. This would lead to memoryleak during driver removal.Properly free memory when the module is removed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cfg80211: call cfg80211_stop_ap when switch from P2P_GO typeIf the userspace tools switch from NL80211_IFTYPE_P2P_GO toNL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), itdoes not call the cleanup cfg80211_stop_ap(), this leads to theinitialization of in-use data. For example, this path re-init thesdata->assigned_chanctx_list while it is still an element ofassigned_vifs list, and makes that linked list corrupt.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove()Prior to this patch in case mlx5_core_destroy_cq() failed it proceedsto rest of destroy operations. mlx5_core_destroy_cq() could be called againby user and cause additional call of mlx5_debug_cq_remove().cq->dbg was not nullify in previous call and cause the crash.Fix it by nullify cq->dbg pointer after removal.Also proceed to destroy operations only if FW return 0for MLX5_CMD_OP_DESTROY_CQ command.general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTICPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:lockref_get+0x1/0x60Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 0200 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 1748 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffeRDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0Call Trace: simple_recursive_removal+0x33/0x2e0 ? debugfs_remove+0x60/0x60 debugfs_remove+0x40/0x60 mlx5_debug_cq_remove+0x32/0x70 [mlx5_core] mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core] devx_obj_cleanup+0x151/0x330 [mlx5_ib] ? __pollwait+0xd0/0xd0 ? xas_load+0x5/0x70 ? xa_load+0x62/0xa0 destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs] uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs] uobj_destroy+0x54/0xa0 [ib_uverbs] ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs] ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs] ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs] __x64_sys_ioctl+0x3e4/0x8e0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routineAn error is detected with the following report when unloading the driver: "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but theflag is not cleared upon completion of the login.This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi setto LPFC_RPI_ALLOW_ERROR. This results in a use after free access when usedas an rpi_ids array index.Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag inlpfc_mbx_cmpl_fc_reg_login().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: free q_vectors before queues in iavf_disable_vfiavf_free_queues() clears adapter->num_active_queues, whichiavf_free_q_vectors() relies on, so swap the order of these two functioncalls in iavf_disable_vf(). This resolves a panic encountered when theinterface is disabled and then later brought up again after PFcommunication is restored.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: Fix NULL pointer dereferences in of_thermal_ functionsof_parse_thermal_zones() parses the thermal-zones node and registers athermal_zone device for each subnode. However, if a thermal zone isconsuming a thermal sensor and that thermal sensor device hasn't probedyet, an attempt to set trip_point_*_temp for that thermal zone devicecan cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200While at it, fix the possible NULL pointer dereference in otherfunctions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),of_thermal_get_trend().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()When parsing the txq list in lpfc_drain_txq(), the driver attempts to passthe requests to the adapter. If such an attempt fails, a local "fail_msg"string is set and a log message output. The job is then added to acompletions list for cancellation.Processing of any further jobs from the txq list continues, but since"fail_msg" remains set, jobs are added to the completions list regardlessof whether a wqe was passed to the adapter. If successfully added totxcmplq, jobs are added to both lists resulting in list corruption.Fix by clearing the fail_msg string after adding a job to the completionslist. This stops the subsequent jobs from being added to the completionslist unless they had an appropriate failure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dpaa2-eth: fix use-after-free in dpaa2_eth_removeAccess to netdev after free_netdev() will cause use-after-free bug.Move debug log before free_netdev() call to avoid it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: sunxi-ng: Unregister clocks/resets when unbindingCurrently, unbinding a CCU driver unmaps the device's MMIO region, whileleaving its clocks/resets and their providers registered. This can causea page fault later when some clock operation tries to perform MMIO. Fixthis by separating the CCU initialization from the memory allocation,and then using a devres callback to unregister the clocks and resets.This also fixes a memory leak of the `struct ccu_reset`, and uses thecorrect owner (the specific platform driver) for the clocks and resets.Early OF clock providers are never unregistered, and limited errorhandling is possible, so they are mostly unchanged. The error reportingis made more consistent by moving the message inside of_sunxi_ccu_probe.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: ohci-tmio: check return value after calling platform_get_resource()It will cause null-ptr-deref if platform_get_resource() returns NULL,we need check the return value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: gus: fix null pointer dereference on pointer blockThe pointer block return from snd_gf1_dma_next_block could benull, so there is a potential null pointer dereference issue.Fix this by adding a null check before dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix null pointer dereference on pointer cs_descThe pointer cs_desc return from snd_usb_find_clock_source couldbe null, so there is a potential null pointer dereference issue.Fix this by adding a null check before dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Update error handler for UCTX and UMEMIn the fast unload flow, the device state is set to internal error,which indicates that the driver started the destroy process.In this case, when a destroy command is being executed, it should returnMLX5_CMD_STAT_OK.Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OKinstead of EIO.This fixes a call trace in the umem release process -[ 2633.536695] Call Trace:[ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs][ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core][ 2633.539641] disable_device+0x8c/0x130 [ib_core][ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core][ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core][ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib][ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary][ 2633.544661] device_release_driver_internal+0x103/0x1f0[ 2633.545679] bus_remove_device+0xf7/0x170[ 2633.546640] device_del+0x181/0x410[ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core][ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core][ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core][ 2633.550864] remove_one+0x69/0xe0 [mlx5_core][ 2633.551819] pci_device_remove+0x3b/0xc0[ 2633.552731] device_release_driver_internal+0x103/0x1f0[ 2633.553746] unbind_store+0xf6/0x130[ 2633.554657] kernfs_fop_write+0x116/0x190[ 2633.555567] vfs_write+0xa5/0x1a0[ 2633.556407] ksys_write+0x4f/0xb0[ 2633.557233] do_syscall_64+0x5b/0x1a0[ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 2633.559018] RIP: 0033:0x7f9977132648[ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup failsCheck for a valid hv_vp_index array prior to derefencing hv_vp_index whensetting Hyper-V's TSC change callback. If Hyper-V setup failed inhyperv_init(), the kernel will still report that it's running underHyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()The following issue was observed running syzkaller:BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118 print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034 __blk_run_queue_uncond block/blk-core.c:464 [inline] __blk_run_queue+0x1a4/0x380 block/blk-core.c:484 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0 drivers/scsi/sg.c:622 __vfs_write+0xed/0x690 fs/read_write.c:485kill_bdev:block_device:00000000e138492c vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbeWe get 'alen' from command its type is int. If userspace passes a largelength we will get a negative 'alen'.Switch n, alen, and rlen to u32.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix vlan tunnel dst refcnt when egressingThe egress tunnel code uses dst_clone() and directly sets the resultwhich is wrong because the entry might have 0 refcnt or be already deleted,causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]when a refcnt couldn't be taken. Fix it by using dst_hold_safe() andchecking if a reference was actually taken before setting the dst.[1] dmesg WARN_ON log and following refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge] __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ? br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ? vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge] __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix vlan tunnel dst null pointer dereferenceThis patch fixes a tunnel_dst null pointer dereference due to locklessaccess in the tunnel egress path. When deleting a vlan tunnel thetunnel_dst pointer is set to NULL without waiting a grace period (i.e.while it's still usable) and packets egressing are dereferencing itwithout checking. Use READ/WRITE_ONCE to annotate the lockless use oftunnel_id, use RCU for accessing tunnel_dst and make sure it is readonly once and checked in the egress path. The dst is already properly RCUprotected so we don't need to do anything fancy than to make suretunnel_id and tunnel_dst are read only once and checked in the egress path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: aardvark: Fix kernel panic during PIO transferTrying to start a new PIO transfer by writing value 0 in PIO_START registerwhen previous transfer has not yet completed (which is indicated by value 1in PIO_START) causes an External Abort on CPU, which results in kernelpanic: SError Interrupt on CPU0, code 0xbf000002 -- SError Kernel panic - not syncing: Asynchronous SError InterruptTo prevent kernel panic, it is required to reject a new PIO transfer whenprevious one has not finished yet.If previous PIO transfer is not finished yet, the kernel may issue a newPIO request only if the previous PIO transfer timed out.In the past the root cause of this issue was incorrectly identified (as itoften happens during link retraining or after link down event) and specialhack was implemented in Trusted Firmware to catch all SError events in EL3,to ignore errors with code 0xbf000002 and not forwarding any other errorsto kernel and instead throw panic from EL3 Trusted Firmware handler.Links to discussion and patches about this issue:https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541But the real cause was the fact that during link retraining or after linkdown event the PIO transfer may take longer time, up to the 1.44s until ittimes out. This increased probability that a new PIO transfer would beissued by kernel while previous one has not finished yet.After applying this change into the kernel, it is possible to revert thementioned TF-A hack and SError events do not have to be caught in TF-A EL3.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: fix memory leak in mcba_usbSyzbot reported memory leak in SocketCAN driver for Microchip CAN BUSAnalyzer Tool. The problem was in unfreed usb_coherent.In mcba_usb_start() 20 coherent buffers are allocated and there isnothing, that frees them:1) In callback function the urb is resubmitted and that's all2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see mcba_usb_start) and this flag cannot be used with coherent buffers.Fail log:| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)So, all allocated buffers should be freed with usb_free_coherent()explicitlyNOTE:The same pattern for allocating and freeing coherent buffersis used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: fix potential use-after-free in ec_bhf_removestatic void ec_bhf_remove(struct pci_dev *dev){... struct ec_bhf_priv *priv = netdev_priv(net_dev); unregister_netdev(net_dev); free_netdev(net_dev); pci_iounmap(dev, priv->dma_io); pci_iounmap(dev, priv->io);...}priv is netdev private data, but it is usedafter free_netdev(). It can cause use-after-free when accessing privpointer. So, fix it by moving free_netdev() after pci_iounmap()calls.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cdc_eem: fix tx fixup skb leakwhen usbnet transmit a skb, eem fixup it in eem_tx_fixup(),if skb_copy_expand() failed, it return NULL,usbnet_start_xmit() will have no chance to free original skb.fix it by free orginal skb in eem_tx_fixup() first,then check skb clone status, if failed, return NULL to usbnet.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix memory leak in ip_mc_add1_srcBUG: memory leakunreferenced object 0xffff888101bc4c00 (size 32): comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................ backtrace: [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline] [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline] [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline] [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095 [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416 [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline] [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423 [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857 [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117 [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline] [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline] [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125 [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47 [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xaeIn commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when setlink down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,because it was also called in igmpv3_clear_delrec().Rough callgraph:inetdev_destroy-> ip_mc_destroy_dev -> igmpv3_clear_delrec -> ip_mc_clear_src-> RCU_INIT_POINTER(dev->ip_ptr, NULL)However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn'trelease in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns theNULL to dev->ip_ptr. As a result, in_dev cannot be obtained throughinetdev_by_index() and then in_dev->mc_list->sources cannot be releasedby ip_mc_del1_src() in the sock_close. Rough call sequence goes like:sock_close-> __sock_release -> inet_release -> ip_mc_drop_socket -> inetdev_by_index -> ip_mc_leave_src -> ip_mc_del_src -> ip_mc_del1_srcSo we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to freein_dev->mc_list->sources.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: fix possible use-after-free in smsc75xx_bindThe commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind")fails to clean up the work scheduled in smsc75xx_reset->smsc75xx_set_multicast, which leads to use-after-free if the work isscheduled to start after the deallocation. In addition, this patchalso removes a dangling pointer - dev->data[0].This patch calls cancel_work_sync to cancel the scheduled work and setthe dangling pointer to NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: synproxy: Fix out of bounds when parsing TCP optionsThe TCP option parser in synproxy (synproxy_parse_options) could readone byte out of bounds. When the length is 1, the execution flow getsinto the loop, reads one byte of the opcode, and if the opcode isneither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceedsthe length of 1.This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stackout of bounds when parsing TCP options.").v2 changes:Added an early return when length < 0 to avoid callingskb_header_pointer with negative length.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: fix null deref in parse dev addrFix a logic error that could result in a null deref if the user setsthe mode incorrectly for the given addr type.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a potential NULL dereference in nfs_get_client()None of the callers are expecting NULL returns from nfs_get_client() sothis code will lead to an Oops. It's better to return an errorpointer. I expect that this is dead code so hopefully no one isaffected.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA: Verify port when creating flow ruleValidate port value provided by the user and with that remove no longerneeded validation by the driver. The missing check in the mlx5_ib drivercould cause to the below oops.Call trace: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 el0_svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: fix various gadget panics on 10gbps cablingusb_assign_descriptors() is called with 5 parameters,the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps).The differences between full/high/super-speed descriptors are usuallysubstantial (due to changes in the maximum usb block size from 64 to 512to 1024 bytes and other differences in the specs), while the differencebetween 5 and 10Gbps descriptors may be as little as nothing(in many cases the same tuning is simply good enough).However if a gadget driver calls usb_assign_descriptors() witha NULL descriptor for super-speed-plus and is then used on a max 10gbpsconfiguration, the kernel will crash with a null pointer dereference,when a 10gbps capable device port + cable + host port combination shows up.(This wouldn't happen if the gadget max-speed was set to 5gbps, butit of course defaults to the maximum, and there's no real reason toartificially limit it)The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,if a 10gbps descriptor wasn't provided.Obviously this won't fix the problem if the 5gbps descriptor is alsoNULL, but such cases can't be so trivially solved (and any such gadgetsare unlikely to be used with USB3 ports any way).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: ep0: fix NULL pointer exceptionThere is no validation of the index from dwc3_wIndex_to_dep() and we mightbe referring a non-existing ep and trigger a NULL pointer exception. Incertain configurations we might use fewer eps and the index might wronglyindicate a larger ep index than existing.By adding this validation from the patch we can actually report a wrongindex back to the caller.In our usecase we are using a composite device on an older kernel, butupstream might use this fix also. Unfortunately, I cannot describe thehardware for others to reproduce the issue as it is a proprietaryimplementation.[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4[ 82.966891] Mem abort info:[ 82.969663] ESR = 0x96000006[ 82.972703] Exception class = DABT (current EL), IL = 32 bits[ 82.978603] SET = 0, FnV = 0[ 82.981642] EA = 0, S1PTW = 0[ 82.984765] Data abort info:[ 82.987631] ISV = 0, ISS = 0x00000006[ 82.991449] CM = 0, WnR = 0[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94...[ 83.141788] Call trace:[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94[ 83.181546] ---[ end trace aac6b5267d84c32f ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: fix various gadgets null ptr deref on 10gbps cabling.This avoids a null pointer dereference inf_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}by simply reusing the 5gbps config for 10gbps.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Correct the length check which causes memory corruptionWe've suffered from severe kernel crashes due to memory corruption onour production environment, like,Call Trace:[1640542.554277] general protection fault: 0000 [#1] SMP PTI[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:0000000006e931bf[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:ffff9a45ff004300[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:0000000000000000[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:ffffffff9a20608d[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:696c662f65636976[1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)knlGS:0000000000000000[1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:00000000003606e0[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[1640542.566742] Call Trace:[1640542.567009] anon_vma_clone+0x5d/0x170[1640542.567417] __split_vma+0x91/0x1a0[1640542.567777] do_munmap+0x2c6/0x320[1640542.568128] vm_munmap+0x54/0x70[1640542.569990] __x64_sys_munmap+0x22/0x30[1640542.572005] do_syscall_64+0x5b/0x1b0[1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9[1640542.575642] RIP: 0033:0x7f45d6e61e27James Wang has reproduced it stably on the latest 4.19 LTS.After some debugging, we finally proved that it's due to ftracebuffer out-of-bound access using a debug tool as follows:[ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000[ 86.780806] no_context+0xdf/0x3c0[ 86.784327] __do_page_fault+0x252/0x470[ 86.788367] do_page_fault+0x32/0x140[ 86.792145] page_fault+0x1e/0x30[ 86.795576] strncpy_from_unsafe+0x66/0xb0[ 86.799789] fetch_memory_string+0x25/0x40[ 86.804002] fetch_deref_string+0x51/0x60[ 86.808134] kprobe_trace_func+0x32d/0x3a0[ 86.812347] kprobe_dispatcher+0x45/0x50[ 86.816385] kprobe_ftrace_handler+0x90/0xf0[ 86.820779] ftrace_ops_assist_func+0xa1/0x140[ 86.825340] 0xffffffffc00750bf[ 86.828603] do_sys_open+0x5/0x1f0[ 86.832124] do_syscall_64+0x5b/0x1b0[ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9commit b220c049d519 ("tracing: Check length before giving outthe filter buffer") adds length check to protect trace dataoverflow introduced in 0fc1b09ff1ff, seems that this fix can't preventoverflow entirely, the length check should also take the sizeofentry->array[0] into account, since this array[0] is filled thelength of trace data and occupy addtional space and risk overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: avoid oversized read request in cache missing code pathIn the cache missing code path of cached device, if a proper locationfrom the internal B+ tree is matched for a cache miss range, functioncached_dev_cache_miss() will be called in cache_lookup_fn() in thefollowing code block,[code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors);Here s->d->cache_miss() is the call backfunction pointer initialized ascached_dev_cache_miss(), the last parameter 'sectors' is an importanthint to calculate the size of read request to backing device of themissing cache data.Current calculation in above code block may generate oversized value of'sectors', which consequently may trigger 2 different potential kernelpanics by BUG() or BUG_ON() as listed below,1) BUG_ON() inside bch_btree_insert_key(),[code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k));2) BUG() inside biovec_slab(),[code block 3] 51 default: 52 BUG(); 53 return NULL;All the above panics are original from cached_dev_cache_miss() by theoversized parameter 'sectors'.Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculatethe size of data read from backing device for the cache missing. Thissize is stored in s->insert_bio_sectors by the following lines of code,[code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);Then the actual key inserting to the internal B+ tree is generated andstored in s->iop.replace_key by the following lines of code,[code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors);The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() fromthe above code block.And the bio sending to backing device for the missing data is allocatedwith hint from s->insert_bio_sectors by the following lines of code,[code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split);The oversized parameter 'sectors' may trigger panic 2) by BUG() from theagove code block.Now let me explain how the panics happen with the oversized 'sectors'.In code block 5, replace_key is generated by macro KEY(). From thedefinition of macro KEY(),[code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 })Here 'size' is 16bits width embedded in 64bits member 'high' of structbkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" isvery probably to be larger than (1<<16) - 1, which makes the bkey sizecalculation in code block 5 is overflowed. In one bug report the valueof parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors'results the overflowed s->insert_bio_sectors in code block 4, then makessize field of s->iop.replace_key to be 0 in code block 5. Then the 0-sized s->iop.replace_key is inserted into the internal B+ tree as cachemissing check key (a special key to detect and avoid a racing betweennormal write request and cache missing read request) as,[code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key);Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkeysize check BUG_ON() in code block 2, and causes the kernel panic 1).Another ke---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Do not blindly read the ip address in ftrace_bug()It was reported that a bug on arm64 caused a bad ip address to be used forupdating into a nop in ftrace_init(), but the error path (rightfully)returned -EINVAL and not -EFAULT, as the bug caused more than one error tooccur. But because -EINVAL was returned, the ftrace_bug() tried to reportwhat was at the location of the ip address, and read it directly. Thiscaused the machine to panic, as the ip was not pointing to a valid memoryaddress.Instead, read the ip address with copy_from_kernel_nofault() to safelyaccess the memory, and if it faults, report that the address faulted,otherwise report what was in that location.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kvm: avoid speculation-based attacks from out-of-range memslot accessesKVM's mechanism for accessing guest memory translates a guest physicaladdress (gpa) to a host virtual address using the right-shifted gpa(also known as gfn) and a struct kvm_memory_slot. The translation isperformed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZEIt is expected that gfn falls within the boundaries of the guest'sphysical memory. However, a guest can access invalid physical addressesin such a way that the gfn is invalid.__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which firstretrieves a memslot through __gfn_to_memslot. While __gfn_to_memslotdoes check that the gfn falls within the boundaries of the guest'sphysical memory or not, a CPU can speculate the result of the check andcontinue execution speculatively using an illegal gfn. The speculationcan result in calculating an out-of-bounds hva. If the resulting hostvirtual address is used to load another guest physical address, thisis effectively a Spectre gadget consisting of two consecutive reads,the second of which is data dependent on the first.Right now it's not clear if there are any cases in which this isexploitable. One interesting case was reported by the original authorof this patch, and involves visiting guest page tables on x86. Rightnow these are not vulnerable because the hva read goes through get_user(),which contains an LFENCE speculation barrier. However, there arepatches in progress for x86 uaccess.h to mask kernel addresses instead ofusing LFENCE; once these land, a guest could use speculation to readfrom the VMM's ring 3 address space. Other architectures such as ARMalready use the address masking method, and would be susceptible tothis same kind of data-dependent access gadgets. Therefore, this patchproactively protects from these attacks by masking out-of-bounds gfnsin __gfn_to_hva_memslot, which blocks speculation of invalid hvas.Sean Christopherson noted that this patch does not coverkvm_read_guest_offset_cached. This however is limited to a few bytespast the end of the cache, and therefore it is unlikely to be useful inthe context of building a chain of data dependent accesses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: Fix use-after-free read in drm_getunique()There is a time-of-check-to-time-of-use error in drm_getunique() dueto retrieving file_priv->master prior to locking the device's mastermutex.An example can be seen in the crash report of the use-after-free errorfound by Syzbot:https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803In the report, the master pointer was used after being freed. This isbecause another process had acquired the device's master mutex indrm_setmaster_ioctl(), then overwrote fpriv->master indrm_new_set_master(). The old value of fpriv->master was subsequentlyfreed before the mutex was unlocked.To fix this, we lock the device's master mutex before retrieving thepointer from from fpriv->master. This patch passes the Syzbotreproducer test.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: seq: Fix race of snd_seq_timer_open()The timer instance per queue is exclusive, and snd_seq_timer_open()should have managed the concurrent accesses. It looks as if it'schecking the already existing timer instance at the beginning, butit's not right, because there is no protection, hence any laterconcurrent call of snd_seq_timer_open() may override the timerinstance easily. This may result in UAF, as the leftover timerinstance can keep running while the queue itself gets closed, asspotted by syzkaller recently.For avoiding the race, add a proper check at the assignment oftmr->timeri again, and return -EBUSY if it's been already registered.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isdn: mISDN: netjet: Fix crash in nj_probe:'nj_setup' in netjet.c might fail with -EIO and in this case'card->irq' is initialized and is bigger than zero. A subsequent call to'nj_release' will free the irq that has not been requested.Fix this bug by deleting the previous assignment to 'card->irq' and justkeep the assignment before 'request_irq'.The KASAN's log reveals it:[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826free_irq+0x100/0x480[ 3.355112 ] Modules linked in:[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted5.13.0-rc1-00144-g25a1298726e #13[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOSrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 184d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:0000000000000000[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:00000000ffffffff[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:0000000000000000[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:0000000000000000[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:ffff888104dc80a8[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)knlGS:0000000000000000[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:00000000000006f0[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[ 3.362175 ] Call Trace:[ 3.362175 ] nj_release+0x51/0x1e0[ 3.362175 ] nj_probe+0x450/0x950[ 3.362175 ] ? pci_device_remove+0x110/0x110[ 3.362175 ] local_pci_probe+0x45/0xa0[ 3.362175 ] pci_device_probe+0x12b/0x1d0[ 3.362175 ] really_probe+0x2a9/0x610[ 3.362175 ] driver_probe_device+0x90/0x1d0[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20[ 3.362175 ] device_driver_attach+0x68/0x70[ 3.362175 ] __driver_attach+0x124/0x1b0[ 3.362175 ] ? device_driver_attach+0x70/0x70[ 3.362175 ] bus_for_each_dev+0xbb/0x110[ 3.362175 ] ? rdinit_setup+0x45/0x45[ 3.362175 ] driver_attach+0x27/0x30[ 3.362175 ] bus_add_driver+0x1eb/0x2a0[ 3.362175 ] driver_register+0xa9/0x180[ 3.362175 ] __pci_register_driver+0x82/0x90[ 3.362175 ] ? w6692_init+0x38/0x38[ 3.362175 ] nj_init+0x36/0x38[ 3.362175 ] do_one_initcall+0x7f/0x3d0[ 3.362175 ] ? rdinit_setup+0x45/0x45[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80[ 3.362175 ] kernel_init_freeable+0x2aa/0x301[ 3.362175 ] ? rest_init+0x2c0/0x2c0[ 3.362175 ] kernel_init+0x18/0x190[ 3.362175 ] ? rest_init+0x2c0/0x2c0[ 3.362175 ] ? rest_init+0x2c0/0x2c0[ 3.362175 ] ret_from_fork+0x1f/0x30[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted5.13.0-rc1-00144-g25a1298726e #13[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOSrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014[ 3.362175 ] Call Trace:[ 3.362175 ] dump_stack+0xba/0xf5[ 3.362175 ] ? free_irq+0x100/0x480[ 3.362175 ] panic+0x15a/0x3f2[ 3.362175 ] ? __warn+0xf2/0x150[ 3.362175 ] ? free_irq+0x100/0x480[ 3.362175 ] __warn+0x108/0x150[ 3.362175 ] ? free_irq+0x100/0x480[ 3.362175 ] report_bug+0x119/0x1c0[ 3.362175 ] handle_bug+0x3b/0x80[ 3.362175 ] exc_invalid_op+0x18/0x70[ 3.362175 ] asm_exc_invalid_op+0x12/0x20[ 3.362175 ] RIP: 0010:free_irq+0x100---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: fix NULL pointer dereferenceCommit 71f642833284 ("ACPI: utils: Fix reference counting infor_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointerthat was possibly NULL. That fails miserably, because that helperinline function is not set up to handle that case.Just make acpi_dev_put() silently accept a NULL pointer, rather thancalling down to put_device() with an invalid offset off that NULLpointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Decrease sock refcount when sock timers expireCommit 63346650c1a9 ("netrom: switch to sock timer API") switched to usesock timer API. It replaces mod_timer() by sk_reset_timer(), anddel_timer() by sk_stop_timer().Function sk_reset_timer() will increase the refcount of sock if it iscalled on an inactive timer, hence, in case the timer expires, we need todecrease the refcount ourselves in the handler, otherwise, the sockrefcount will be unbalanced and the sock will never be freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix memory leak in tcindex_partial_destroy_workSyzbot reported memory leak in tcindex_set_parms(). The problem was innon-freed perfect hash in tcindex_partial_destroy_work().In tcindex_set_parms() new tcindex_data is allocated and some fields fromold one are copied to new one, but not the perfect hash. Sincetcindex_partial_destroy_work() is the destroy function for oldtcindex_data, we need to free perfect hash to avoid memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix uninit-value in caif_seqpkt_sendmsgWhen nr_segs equal to zero in iovec_from_user, the objectmsg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsgwhich is defined in ___sys_sendmsg. So we cann't just judgemsg->msg_iter.iov->base directlly. We can use nr_segs to judgemsg in caif_seqpkt_sendmsg whether has data buffers.=====================================================BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmmsg+0x808/0xc90 net/socket.c:2480 __compat_sys_sendmmsg net/compat.c:656 [inline]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/sync_file: Don't leak fences on merge failureEach add_fence() call does a dma_fence_get() on the relevant fence. Inthe error path, we weren't calling dma_fence_put() so all those fencesgot leaked. Also, in the krealloc_array failure case, we weren'tfreeing the fences array. Instead, ensure that i and fences are alwayszero-initialized and dma_fence_put() all the fences and kfree(fences) onevery error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent NULL deref in cifs_compose_mount_options()The optional @ref parameter might contain an NULL node_name, soprevent dereferencing it in cifs_compose_mount_options().Addresses-Coverity: 1476408 ("Explicit null dereferenced")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libfc: Fix array index out of bound exceptionFix array index out of bound exception in fc_rport_prli_resp().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: validate lwtstate->data before returning from skb_tunnel_info()skb_tunnel_info() returns pointer of lwtstate->data as ip_tunnel_infotype without validation. lwtstate->data can have various types such asmpls_iptunnel_encap, etc and these are not compatible.So skb_tunnel_info() should validate before returning that pointer.Splat looks like:BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan]Read of size 2 at addr ffff888106ec2698 by task ping/811CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195Call Trace: dump_stack_lvl+0x56/0x7b print_address_description.constprop.8.cold.13+0x13/0x2ee ? vxlan_get_route+0x418/0x4b0 [vxlan] ? vxlan_get_route+0x418/0x4b0 [vxlan] kasan_report.cold.14+0x83/0xdf ? vxlan_get_route+0x418/0x4b0 [vxlan] vxlan_get_route+0x418/0x4b0 [vxlan] [ ... ] vxlan_xmit_one+0x148b/0x32b0 [vxlan] [ ... ] vxlan_xmit+0x25c5/0x4780 [vxlan] [ ... ] dev_hard_start_xmit+0x1ae/0x6e0 __dev_queue_xmit+0x1f39/0x31a0 [ ... ] neigh_xmit+0x2f9/0x940 mpls_xmit+0x911/0x1600 [mpls_iptunnel] lwtunnel_xmit+0x18f/0x450 ip_finish_output2+0x867/0x2040 [ ... ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ti: fix UAF in tlan_remove_onepriv is netdev private data and it cannot beused after free_netdev() call. Using priv after free_netdev()can cause UAF bug. Fix it by moving free_netdev() at the end of thefunction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Fix NULL pointer dereference in udf_symlink functionIn function udf_symlink, epos.bh is assigned with the value returnedby udf_tgetblk. The function udf_tgetblk is defined in udf/misc.cand returns the value of sb_getblk function that could be NULL.Then, epos.bh is used without any check, causing a possibleNULL pointer dereference when sb_getblk fails.This fix adds a check to validate the value of epos.bh.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: schedutil: Use kobject release() method to free sugov_tunablesThe struct sugov_tunables is protected by the kobject, so we can't freeit directly. Otherwise we would get a call trace like this: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30 WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001ecaf910 x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80 x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000 x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20 x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010 x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365 x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69 x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0 x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001 x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000 x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1c0/0x230 debug_check_no_obj_freed+0x20/0x88 slab_free_freelist_hook+0x154/0x1c8 kfree+0x114/0x5d0 sugov_exit+0xbc/0xc0 cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x268/0x4a8 store_scaling_governor+0xe0/0x128 store+0xc0/0xf0 sysfs_kf_write+0x54/0x80 kernfs_fop_write_iter+0x128/0x1c0 new_sync_write+0xf0/0x190 vfs_write+0x2d4/0x478 ksys_write+0x74/0x100 __arm64_sys_write+0x24/0x30 invoke_syscall.constprop.0+0x54/0xe0 do_el0_svc+0x64/0x158 el0_svc+0x2c/0xb0 el0t_64_sync_handler+0xb0/0xb8 el0t_64_sync+0x198/0x19c irq event stamp: 5518 hardirqs last enabled at (5517): [] console_unlock+0x554/0x6c8 hardirqs last disabled at (5518): [] el1_dbg+0x28/0xa0 softirqs last enabled at (5504): [] __do_softirq+0x4d0/0x6c0 softirqs last disabled at (5483): [] irq_exit+0x1b0/0x1b8So split the original sugov_tunables_free() into two functions,sugov_clear_global_tunables() is just used to clear the global_tunablesand the new sugov_tunables_free() is used as kobj_type::release torelease the sugov_tunables safely.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotapLimit max values for vht mcs and nss in ieee80211_parse_tx_radiotaproutine in order to fix the following warning reported by syzbot:WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244Modules linked in:CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600Call Trace: ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [inline] __bpf_redirect_no_mac net/core/filter.c:2139 [inline] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 ____bpf_clone_redirect net/core/filter.c:2429 [inline] bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline] __bpf_prog_run include/linux/filter.h:624 [inline] bpf_prog_run include/linux/filter.h:631 [inline] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline] __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline] __se_sys_bpf kernel/bpf/syscall.c:4689 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x4665f9
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211-hwsim: fix late beacon hrtimer handlingThomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglxthat our handling of the hrtimer here is wrong: If the timer fireslate (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)then it tries to actually rearm the timer at the next deadline,which might be in the past already: 1 2 3 N N+1 | | | ... | | ^ intended to fire here (1) ^ next deadline here (2) ^ actually fired hereThe next time it fires, it's later, but will still try to schedulefor the next deadline (now 3), etc. until it catches up with N,but that might take a long time, causing stalls etc.Now, all of this is simulation, so we just have to fix it, butnote that the behaviour is wrong even per spec, since there's novalue then in sending all those beacons unaligned - they should bealigned to the TBTT (1, 2, 3, ... in the picture), and if we're abit (or a lot) late, then just resume at that point.Therefore, change the code to use hrtimer_forward_now() which willensure that the next firing of the timer would be at N+1 (in thepicture), i.e. the next interval point after the current time.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootbWe should always check if skb_header_pointer's return is NULL beforeusing it, otherwise it may cause null-ptr-deref, as syzbot reported: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196 Call Trace: sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setupThe ixgbe driver currently generates a NULL pointer dereference withsome machine (online cpus < 63). This is due to the fact that themaximum value of num_xdp_queues is nr_cpu_ids. Code is in"ixgbe_set_rss_queues"".Here's how the problem repeats itself:Some machine (online cpus < 63), And user set num_queues to 63 throughethtool. Code is in the "ixgbe_set_channels", adapter->ring_feature[RING_F_FDIR].limit = count;It becomes 63.When user use xdp, "ixgbe_set_rss_queues" will set queues num. adapter->num_rx_queues = rss_i; adapter->num_tx_queues = rss_i; adapter->num_xdp_queues = ixgbe_xdp_queues(adapter);And rss_i's value is from f = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit;So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup", for (i = 0; i < adapter->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem)It leads to panic.Call trace:[exception RIP: ixgbe_xdp+368]RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808 9 [ffff9fe16202f960] do_setlink at ffffffffa8a2023510 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a2038411 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f8814 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a7131915 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df29016 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c817 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a6418 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b919 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008cSo I fix ixgbe_max_channels so that it will not allow a setting of queuesto be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,take the smaller value of num_rx_queues and num_xdp_queues.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipack: ipoctal: fix stack information leakThe tty driver name is used also after registering the driver and mustspecifically not be allocated on the stack to avoid leaking informationto user space (or triggering an oops).Drivers should not try to encode topology information in the tty devicename but this one snuck in through staging without anyone noticing andanother driver has since copied this malpractice.Fixing the ABI is a separate issue, but this at least plugs the securityhole.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipack: ipoctal: fix module reference leakA reference to the carrier module was taken on every open but was onlyreleased once when the final reference to the tty struct was dropped.Fix this by taking the module reference and initialising the tty driverdata when installing the tty.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: free raw_report buffers in usbhid_stopFree the unsent raw_report buffers when the device is removed.Fixes a memory leak reported by syzbot at:https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc2: check return value after calling platform_get_resource()It will cause null-ptr-deref if platform_get_resource() returns NULL,we need check the return value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix freeing of uninitialized misc IRQ vectorWhen VSI set up failed in i40e_probe() as part of PF switch set updriver was trying to free misc IRQ vectors ini40e_clear_interrupt_scheme and produced a kernel Oops: Trying to free already-free IRQ 266 WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Workqueue: events work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Call Trace: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0 ? acpi_ut_update_ref_count.part.1+0x8e/0x345 ? acpi_ut_update_object_reference+0x15e/0x1e2 ? strstr+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0 ? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0 ? acpi_register_gsi_ioapic+0x93/0x170 ? pci_conf1_read+0xa4/0x100 ? pci_bus_read_config_word+0x49/0x70 ? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40The problem is that at that point misc IRQ vectorswere not allocated yet and we get a call tracethat driver is trying to free already free IRQ vectors.Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTEDPF state before calling i40e_free_misc_vector. This state is set only ifmisc IRQ vectors were properly initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: acpi: fix resource leak in reconfiguration device additionacpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes areference on the adapter which is never released which will result in areference count leak and render the adapter unremovable. Make sure toput the adapter after creating the client in the same manner that we dofor OF.[wsa: fixed title]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix abort logic in btrfs_replace_file_extentsError injection testing uncovered a case where we'd end up with acorrupt file system with a missing extent in the middle of a file. Thisoccurs because the if statement to decide if we should abort is wrong.The only way we would abort in this case is if we got a ret !=-EOPNOTSUPP and we called from the file clone code. However theprealloc code uses this path too. Instead we need to abort if there isan error, and the only error we _don't_ abort on is -EOPNOTSUPP and onlyif we came from the clone file code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Fix command ring pointer corruption while aborting a commandThe command ring pointer is located at [6:63] bits of the commandring control register (CRCR). All the control bits like command stop,abort are located at [0:3] bits. While aborting a command, we read theCRCR and set the abort bit and write to the CRCR. The read will alwaysgive command ring pointer as all zeros. So we essentially write onlythe control bits. Since we split the 64 bit write into two 32 bit writes,there is a possibility of xHC command ring stopped before the upperdword (all zeros) is written. If that happens, xHC updates the upperdword of its internal command ring pointer with all zeros. Next time,when the command ring is restarted, we see xHC memory access failures.Fix this issue by only writing to the lower dword of CRCR where allcontrol bits are located.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix mempool NULL pointer race when completing IOdm_io_dec_pending() calls end_io_acct() first and will then dec mdin-flight pending count. But if a task is swapping DM table at sametime this can result in a crash due to mempool->elements being NULL:task1 task2do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 ->dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io[ 67.330330] Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000000......[ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO)[ 67.330510] pc : mempool_free+0x70/0xa0[ 67.330515] lr : mempool_free+0x4c/0xa0[ 67.330520] sp : ffffff8008013b20[ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004[ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8[ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800[ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800[ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80[ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c[ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd[ 67.330563] x15: 000000000093b41e x14: 0000000000000010[ 67.330569] x13: 0000000000007f7a x12: 0000000034155555[ 67.330574] x11: 0000000000000001 x10: 0000000000000001[ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000[ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a[ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001[ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8[ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970[ 67.330609] Call trace:[ 67.330616] mempool_free+0x70/0xa0[ 67.330627] bio_put+0xf8/0x110[ 67.330638] dec_pending+0x13c/0x230[ 67.330644] clone_endio+0x90/0x180[ 67.330649] bio_endio+0x198/0x1b8[ 67.330655] dec_pending+0x190/0x230[ 67.330660] clone_endio+0x90/0x180[ 67.330665] bio_endio+0x198/0x1b8[ 67.330673] blk_update_request+0x214/0x428[ 67.330683] scsi_end_request+0x2c/0x300[ 67.330688] scsi_io_completion+0xa0/0x710[ 67.330695] scsi_finish_command+0xd8/0x110[ 67.330700] scsi_softirq_done+0x114/0x148[ 67.330708] blk_done_softirq+0x74/0xd0[ 67.330716] __do_softirq+0x18c/0x374[ 67.330724] irq_exit+0xb4/0xb8[ 67.330732] __handle_domain_irq+0x84/0xc0[ 67.330737] gic_handle_irq+0x148/0x1b0[ 67.330744] el1_irq+0xe8/0x190[ 67.330753] lpm_cpuidle_enter+0x4f8/0x538[ 67.330759] cpuidle_enter_state+0x1fc/0x398[ 67.330764] cpuidle_enter+0x18/0x20[ 67.330772] do_idle+0x1b4/0x290[ 67.330778] cpu_startup_entry+0x20/0x28[ 67.330786] secondary_start_kernel+0x160/0x170Fix this by:1) Establishing pointers to 'struct dm_io' members indm_io_dec_pending() so that they may be passed into end_io_acct()_after_ free_io() is called.2) Moving end_io_acct() after free_io().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: musb: dsps: Fix the probe error pathCommit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() afterinitializing musb") has inverted the calls todsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() withoutupdating correctly the error path. dsps_create_musb_pdev() allocates andregisters a new platform device which must be unregistered and freedwith platform_device_unregister(), and this is missing upondsps_setup_optional_vbus_irq() error.While on the master branch it seems not to trigger any issue, I observeda kernel crash because of a NULL pointer dereference with a v5.10.70stable kernel where the patch mentioned above was backported. With thiskernel version, -EPROBE_DEFER is returned the first timedsps_setup_optional_vbus_irq() is called which triggers the probe toerror out without unregistering the platform device. Unfortunately, onthe Beagle Bone Black Wireless, the platform device still living in thesystem is being used by the USB Ethernet gadget driver, which during theboot phase triggers the crash.My limited knowledge of the musb world prevents me to revert this commitwhich was sent to silence a robot warning which, as far as I understand,does not make sense. The goal of this patch was to prevent an IRQ tofire before the platform device being registered. I think this cannotever happen due to the fact that enabling the interrupts is done by the->enable() callback of the platform musb device, and this platformdevice must be already registered in order for the core or any otheruser to use this callback.Hence, I decided to fix the error path, which might prevent futureerrors on mainline kernels while also fixing older ones.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error pathPrior to this patch in case mlx5_core_destroy_cq() failed it returnswithout completing all destroy operations and that leads to memory leak.Instead, complete the destroy flow before return error.Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()to be symmetrical with mlx5_core_create_cq().kmemleak complains on:unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230[mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300[mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core] [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: thermal: Fix out-of-bounds memory accessesCurrently, mlxsw allows cooling states to be set above the maximumcooling state supported by the driver: # cat /sys/class/thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0This results in out-of-bounds memory accesses when thermal statetransition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as thetransition table is accessed with a too large index (state) [1].According to the thermal maintainer, it is the responsibility of thedriver to reject such operations [2].Therefore, return an error when the state to be set exceeds the maximumcooling state supported by the driver.To avoid dead code, as suggested by the thermal maintainer [3],partially revert commit a421ce088ac8 ("mlxsw: core: Extend coolingdevice with cooling levels") that tried to interpret these invalidcooling states (above the maximum) in a special way. The cooling levelsarray is not removed in order to prevent the fans going below 20% PWM,which would cause them to get stuck at 0% PWM.[1]BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016Workqueue: events_freezable_power_ thermal_zone_device_checkCall Trace: dump_stack_lvl+0x8b/0xb3 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b thermal_cooling_device_stats_update+0x271/0x290 __thermal_cdev_update+0x15e/0x4e0 thermal_cdev_update+0x9f/0xe0 step_wise_throttle+0x770/0xee0 thermal_zone_device_update+0x3f6/0xdf0 process_one_work+0xa42/0x1770 worker_thread+0x62f/0x13e0 kthread+0x3ee/0x4e0 ret_from_fork+0x1f/0x30Allocated by task 1: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 thermal_cooling_device_setup_sysfs+0x153/0x2c0 __thermal_cooling_device_register.part.0+0x25b/0x9c0 thermal_cooling_device_register+0xb3/0x100 mlxsw_thermal_init+0x5c5/0x7e0 __mlxsw_core_bus_device_register+0xcb3/0x19c0 mlxsw_core_bus_device_register+0x56/0xb0 mlxsw_pci_probe+0x54f/0x710 local_pci_probe+0xc6/0x170 pci_device_probe+0x2b2/0x4d0 really_probe+0x293/0xd10 __driver_probe_device+0x2af/0x440 driver_probe_device+0x51/0x1e0 __driver_attach+0x21b/0x530 bus_for_each_dev+0x14c/0x1d0 bus_add_driver+0x3ac/0x650 driver_register+0x241/0x3d0 mlxsw_sp_module_init+0xa2/0x174 do_one_initcall+0xee/0x5f0 kernel_init_freeable+0x45a/0x4de kernel_init+0x1f/0x210 ret_from_fork+0x1f/0x30The buggy address belongs to the object at ffff8881052f7800 which belongs to the cache kmalloc-1k of size 1024The buggy address is located 1016 bytes inside of 1024-byte region [ffff8881052f7800, ffff8881052f7c00)The buggy address belongs to the page:page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0flags: 0x200000000010200(slab|head|node=0|zone=2)raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67----truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix null pointer dereference on pointer edpThe initialization of pointer dev dereferences pointer edp beforeedp is null checked, so there is a potential null pointer deferenceissue. Fix this by only dereferencing edp after edp has been nullchecked.Addresses-Coverity: ("Dereference before null check")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Fix possible memory leak in ptp_clock_register()I got memory leak as follows when doing fault injection test:unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]When posix_clock_register() returns an error, the name allocatedin dev_set_name() will be leaked, the put_device() should be usedto give up the device reference, then the name will be freed inkobject_cleanup() and other memory will be freed in ptp_clock_release().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: peak_pci: peak_pci_remove(): fix UAFWhen remove the module peek_pci, referencing 'chan' again afterreleasing 'dev' will cause UAF.Fix this by releasing 'dev' later.The following log reveals it:[ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci][ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537[ 35.965513 ] Call Trace:[ 35.965718 ] dump_stack_lvl+0xa8/0xd1[ 35.966028 ] print_address_description+0x87/0x3b0[ 35.966420 ] kasan_report+0x172/0x1c0[ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci][ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170[ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci][ 35.967945 ] __asan_report_load8_noabort+0x14/0x20[ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci][ 35.968752 ] pci_device_remove+0xa9/0x250
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: mount fails with buffer overflow in strlenStarting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting anocfs2 filesystem with either o2cb or pcmk cluster stack fails with thetrace below. Problem seems to be that strings for cluster stack andcluster name are not guaranteed to be null terminated in the diskrepresentation, while strlcpy assumes that the source string is alwaysnull terminated. This causes a read outside of the source stringtriggering the buffer overflow detection. detected buffer overflow in strlen ------------[ cut here ]------------ kernel BUG at lib/string.c:1149! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11 ... Call Trace: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x454/0xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Fix out of bound access for corrupted isofs imageWhen isofs image is suitably corrupted isofs_read_inode() can read databeyond the end of buffer. Sanity-check the directory entry length beforeusing it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm rq: don't queue request to blk-mq during DM suspendDM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue.But blk-mq's unquiesce may come from outside events, such as elevatorswitch, updating nr_requests or others, and request may come duringsuspend, so simply ask for blk-mq to requeue it.Fixes one kernel panic issue when running updating nr_requests anddm-mpath suspend/resume stress test.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix NULL pointer dereference in i40e_dbg_dump_descWhen trying to dump VFs VSI RX/TX descriptorsusing debugfs there was a crashdue to NULL pointer dereference in i40e_dbg_dump_desc.Added a check to i40e_dbg_dump_desc that checks ifVSI type is correct for dumping RX/TX descriptors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: oss: Limit the period size to 16MBSet the practical limit to the period size (the fragment shift in OSS)instead of a full 31bit; a too large value could lead to the exhaustof memory as we allocate temporary buffers of the period size, too.As of this patch, we set to 16MB limit, which should cover all usecases.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()In qlcnic_83xx_add_rings(), the indirect function ofahw->hw_ops->alloc_mbx_args will be called to allocate memory forcmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),which could lead to a NULL pointer dereference on failure of theindirect function like qlcnic_83xx_alloc_mbx_args().Fix this bug by adding a check of alloc_mbx_args(), this patchimitates the logic of mbx_cmd()'s failure handling.This bug was found by a static analyzer. The analysis employsdifferential checking to identify inconsistent security operations(e.g., checks or kfrees) between two code paths and confirms that theinconsistent operations are not recovered in the current function orthe callers, so they constitute bugs.Note that, as a bug found by static analysis, it can be a falsepositive or hard to trigger. Multiple researchers have cross-reviewedthe bug.Builds with CONFIG_QLCNIC=m show no new warnings, and ourstatic analyzer no longer warns about this code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:proc/vmcore: fix clearing user buffer by properly using clear_user()To clear a user buffer we cannot simply use memset, we have to useclear_user(). With a virtio-mem device that registers a vmcore_cb andhas some logically unplugged memory inside an added Linux memory block,I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeSome x86-64 CPUs have a CPU feature called "Supervisor Mode AccessPrevention (SMAP)", which is used to detect wrong access from the kernelto user buffers like this: SMAP triggers a permissions violation onwrong access. In the x86-64 variant of clear_user(), SMAP is properlyhandled via clac()+stac().To fix, properly use clear_user() when we're dealing with a user buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Make do_proc_control() and do_proc_bulk() killableThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invokeusb_start_wait_urb(), which contains an uninterruptible wait with auser-specified timeout value. If timeout value is very large and thedevice being accessed does not respond in a reasonable amount of time,the kernel will complain about "Task X blocked for more than Nseconds", as found in testing by syzbot:INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline] usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713...To fix this problem, this patch replaces usbfs's calls tousb_control_msg() and usb_bulk_msg() with special-purpose code thatdoes essentially the same thing (as recommended in the comment forusb_start_wait_urb()), except that it always uses a killable wait andit uses GFP_KERNEL rather than GFP_NOIO.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mxl111sf: change mutex_init() locationSyzbot reported, that mxl111sf_ctrl_msg() uses uninitializedmutex. The problem was in wrong mutex_init() location.Previous mutex_init(&state->msg_lock) call was in ->init() function, butdvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init()Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()internally we need to initialize state->msg_lock beforefrontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*devices, which will simply initiaize mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: systemport: Add global locking for descriptor lifecycleThe descriptor list is a shared resource across all of the transmit queues, andthe locking mechanism used today only protects concurrency across a giventransmit queue between the transmit and reclaiming. This creates an opportunityfor the SYSTEMPORT hardware to work on corrupted descriptors if we havemultiple producers at once which is the case when using multiple transmitqueues.This was particularly noticeable when using multiple flows/transmit queues andit showed up in interesting ways in that UDP packets would get a correct UDPheader checksum being calculated over an incorrect packet length. Similarly TCPpackets would get an equally correct checksum computed by the hardware over anincorrect packet length.The SYSTEMPORT hardware maintains an internal descriptor list that it re-arrangeswhen the driver produces a new descriptor anytime it writes to theWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware tore-organize its descriptors and it is possible that concurrent TX queueseventually break this internal allocation scheme to the point where thelength/status part of the descriptor gets used for an incorrect data buffer.The fix is to impose a global serialization for all TX queues in the shortsection where we are writing to the WRITE_PORT_{HI,LO} registers which solvesthe corruption even with multiple concurrent TX queues being used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sit: do not call ipip6_dev_free() from sit_init_net()ipip6_dev_free is sit dev->priv_destructor, already calledby register_netdevice() if something goes wrong.Alternative would be to make ipip6_dev_free() robust againstmultiple invocations, but other drivers do not implement thisstrategy.syzbot reported:dst_release underflowWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173Modules linked in:CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2cR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ipv6/sit.c:1414 [inline] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075 __do_sys_unshare kernel/fork.c:3146 [inline] __se_sys_unshare kernel/fork.c:3144 [inline] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f66c882ce99Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igbvf: fix double free in `igbvf_probe`In `igbvf_probe`, if register_netdev() fails, the program will go tolabel err_hw_init, and then to label err_ioremap. In free_netdev() whichis just below label err_ioremap, there is `list_for_each_entry_safe` and`netif_napi_del` which aims to delete all entries in `dev->napi_list`.The program has added an entry `adapter->rx_ring->napi` which is added by`netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring hasbeen freed below label err_hw_init. So this a UAF.In terms of how to patch the problem, we can refer to igbvf_remove() anddelete the entry before `adapter->rx_ring`.The KASAN logs are as follows:[ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450[ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366[ 35.128360][ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14[ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014[ 35.131749] Call Trace:[ 35.132199] dump_stack_lvl+0x59/0x7b[ 35.132865] print_address_description+0x7c/0x3b0[ 35.133707] ? free_netdev+0x1fd/0x450[ 35.134378] __kasan_report+0x160/0x1c0[ 35.135063] ? free_netdev+0x1fd/0x450[ 35.135738] kasan_report+0x4b/0x70[ 35.136367] free_netdev+0x1fd/0x450[ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf][ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf][ 35.138751] local_pci_probe+0x13c/0x1f0[ 35.139461] pci_device_probe+0x37e/0x6c0[ 35.165526][ 35.165806] Allocated by task 366:[ 35.166414] ____kasan_kmalloc+0xc4/0xf0[ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf][ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf][ 35.168866] local_pci_probe+0x13c/0x1f0[ 35.169565] pci_device_probe+0x37e/0x6c0[ 35.179713][ 35.179993] Freed by task 366:[ 35.180539] kasan_set_track+0x4c/0x80[ 35.181211] kasan_set_free_info+0x1f/0x40[ 35.181942] ____kasan_slab_free+0x103/0x140[ 35.182703] kfree+0xe3/0x250[ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf][ 35.184040] local_pci_probe+0x13c/0x1f0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: use latest_dev in btrfs_show_devnameThe test case btrfs/238 reports the warning below: WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs] CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: btrfs_show_devname+0x108/0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 invoke_syscall+0x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x198/0x19cReason:While btrfs_prepare_sprout() moves the fs_devices::devices intofs_devices::seed_list, the btrfs_show_devname() searches for the devicesand found none, leading to the warning as in above.Fix:latest_dev is updated according to the changes to the device list.That means we could use the latest_dev->name to show the device name in/proc/self/mounts, the pointer will be always valid as it's assignedbefore the device is deleted from the list in remove or replace.The RCU protection is sufficient as the device structure is freed aftersynchronization.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac80211: track only QoS data frames for admission controlFor admission control, obviously all of that only works forQoS data frames, otherwise we cannot even access the QoSfield in the header.Syzbot reported (see below) an uninitialized value here dueto a status of a non-QoS nullfunc packet, which isn't evenlong enough to contain the QoS header.Fix this to only do anything for QoS data packets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netlink: af_netlink: Prevent empty skb by adding a check on len.Adding a check on len parameter to avoid empty skb. This prevents adivision error in netem_enqueue function which is caused when skb->len=0and skb->data_len=0 in the randomized corruption step as shown below.skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);Crash Report:[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family0 port 6081 - 0[ 343.216110] netem: version 1.3[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.11.0-2.el7 04/01/2014[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem][ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ffff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f74 f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:0000000000000000[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:ffff88800f8eda40[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:ffffffff94fb8445[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:0000000000000000[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:0000000000000020[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)knlGS:0000000000000000[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:00000000000006e0[ 343.250076] Call Trace:[ 343.250423] [ 343.250713] ? memcpy+0x4d/0x60[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem][ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem][ 343.253102] ? stack_trace_save+0x87/0xb0[ 343.253655] ? filter_irq_stacks+0xb0/0xb0[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem][ 343.254837] ? __kasan_check_write+0x14/0x20[ 343.255418] ? _raw_spin_lock+0x88/0xd6[ 343.255953] dev_qdisc_enqueue+0x50/0x180[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090[ 343.257083] ? netdev_core_pick_tx+0x300/0x300[ 343.257690] ? check_kcov_mode+0x10/0x40[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30[ 343.259529] ? setup_object.isra.71+0x23/0x90[ 343.260121] ? new_slab+0x26e/0x4b0[ 343.260609] ? kasan_poison+0x3a/0x50[ 343.261118] ? kasan_unpoison+0x28/0x50[ 343.261637] ? __kasan_slab_alloc+0x71/0x90[ 343.262214] ? memcpy+0x4d/0x60[ 343.262674] ? write_comp_data+0x2f/0x90[ 343.263209] ? __kasan_check_write+0x14/0x20[ 343.263802] ? __skb_clone+0x5d6/0x840[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.264958] dev_queue_xmit+0x1c/0x20[ 343.265470] netlink_deliver_tap+0x652/0x9c0[ 343.266067] netlink_unicast+0x5a0/0x7f0[ 343.266608] ? netlink_attachskb+0x860/0x860[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.267820] ? write_comp_data+0x2f/0x90[ 343.268367] netlink_sendmsg+0x922/0xe80[ 343.268899] ? netlink_unicast+0x7f0/0x7f0[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.270099] ? write_comp_data+0x2f/0x90[ 343.270644] ? netlink_unicast+0x7f0/0x7f0[ 343.271210] sock_sendmsg+0x155/0x190[ 343.271721] ____sys_sendmsg+0x75f/0x8f0[ 343.272262] ? kernel_sendmsg+0x60/0x60[ 343.272788] ? write_comp_data+0x2f/0x90[ 343.273332] ? write_comp_data+0x2f/0x90[ 343.273869] ___sys_sendmsg+0x10f/0x190[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80[ 343.274984] ? slab_post_alloc_hook+0x70/0x230[ 343.275597] ? futex_wait_setup+0x240/0x240[ 343.276175] ? security_file_alloc+0x3e/0x170[ 343.276779] ? write_comp_d---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Fix string overflow in SCPI genpd driverWithout the bound checks for scpi_pd->name, it could result in the bufferoverflow when copying the SCPI device name from the corresponding devicetree node as the name string is set at maximum size of 30.Let us fix it by using devm_kasprintf so that the string buffer isallocated dynamically.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: fix segfault in nfc_genl_dump_devices_doneWhen kmalloc in nfc_genl_dump_devices() fails thennfc_genl_dump_devices_done() segfaults as belowKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014Workqueue: events netlink_sock_destruct_workRIP: 0010:klist_iter_exit+0x26/0x80Call Trace:class_dev_iter_exit+0x15/0x20nfc_genl_dump_devices_done+0x3b/0x50genl_lock_done+0x84/0xd0netlink_sock_destruct+0x8f/0x270__sk_destruct+0x64/0x3b0sk_destruct+0xa8/0xd0__sk_free+0x2e8/0x3d0sk_free+0x51/0x90netlink_sock_destruct_work+0x1c/0x20process_one_work+0x411/0x710worker_thread+0x6fd/0xa80
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix queues reservation for XDPWhen XDP was configured on a system with large number of CPUsand X722 NIC there was a call trace with NULL pointer dereference.i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12i40e 0000:87:00.0: setup of MAIN VSI failedBUG: kernel NULL pointer dereference, address: 0000000000000000RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]Call Trace:? i40e_reconfig_rss_queues+0x130/0x130 [i40e]dev_xdp_install+0x61/0xe0dev_xdp_attach+0x18a/0x4c0dev_change_xdp_fd+0x1e6/0x220do_setlink+0x616/0x1030? ahci_port_stop+0x80/0x80? ata_qc_issue+0x107/0x1e0? lock_timer_base+0x61/0x80? __mod_timer+0x202/0x380rtnl_setlink+0xe5/0x170? bpf_lsm_binder_transaction+0x10/0x10? security_capable+0x36/0x50rtnetlink_rcv_msg+0x121/0x350? rtnl_calcit.isra.0+0x100/0x100netlink_rcv_skb+0x50/0xf0netlink_unicast+0x1d3/0x2a0netlink_sendmsg+0x22a/0x440sock_sendmsg+0x5e/0x60__sys_sendto+0xf0/0x160? __sys_getsockname+0x7e/0xc0? _copy_from_user+0x3c/0x80? __sys_setsockopt+0xc8/0x1a0__x64_sys_sendto+0x20/0x30do_syscall_64+0x33/0x40entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f83fa7a39e0This was caused by PF queue pile fragmentation due toflow director VSI queue being placed right after main VSI.Because of this main VSI was not able to resize itsqueue allocation for XDP resulting in no queues allocatedfor main VSI when XDP was turned on.Fix this by always allocating last queue in PF queue pilefor a flow director VSI.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_comOn the case tmp_dcim=1, the index of buffer is miscalculated.This generate a NULL pointer dereference later.So let's fix the calcul and add a check to prevent this to reappear.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix a memory leak in 'host1x_remove()'Add a missing 'host1x_channel_list_free()' call in the remove function,as already done in the error handling path of the probe function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()I got a null-ptr-deref report:BUG: kernel NULL pointer dereference, address: 0000000000000000...RIP: 0010:fb_destroy_modelist+0x38/0x100...Call Trace: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460... ret_from_fork+0x1f/0x30If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() willbe called to destroy modelist in the error handling path. But modelisthas not been initialized yet, so it will result in null-ptr-deref.Initialize modelist before calling fb_alloc_cmap() to fix this bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: dev: can_restart: fix use after free bugAfter calling netif_rx_ni(skb), dereferencing skb is unsafe.Especially, the can_frame cf which aliases skb memory is accessedafter the netif_rx_ni() in: stats->rx_bytes += cf->len;Reordering the lines solves the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: vxcan: vxcan_xmit: fix use after free bugAfter calling netif_rx_ni(skb), dereferencing skb is unsafe.Especially, the canfd_frame cfd which aliases skb memory is accessedafter the netif_rx_ni().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: peak_usb: fix use after free bugsAfter calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.Especially, the can_frame cf which aliases skb memory is accessedafter the peak_usb_netif_rx_ni().Reordering the lines solves the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel's filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: Product: AndroidVersions: Android kernelAndroid ID: A-224546354References: Upstream kernel
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: An incorrect read request flaw was found in the Infrared Transceiver USB driver in the Linux kernel. This issue occurs when a user attaches a malicious USB device. A local user could use this flaw to starve the resources, causing denial of service or potentially crashing the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Linux kernel's Layer 2 Tunneling Protocol (L2TP). A missing lock when clearing sk_user_data can lead to a race condition and NULL pointer dereference. A local user could use this flaw to potentially crash the system causing a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0When walking through an inode extents, the ext4_ext_binsearch_idx() functionassumes that the extent header has been previously validated. However, thereare no checks that verify that the number of entries (eh->eh_entries) isnon-zero when depth is > 0. And this will lead to problems because theEXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:[ 135.245946] ------------[ cut here ]------------[ 135.247579] kernel BUG at fs/ext4/extents.c:2258![ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0[ 135.256475] Code:[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0[ 135.277952] Call Trace:[ 135.278635] [ 135.279247] ? preempt_count_add+0x6d/0xa0[ 135.280358] ? percpu_counter_add_batch+0x55/0xb0[ 135.281612] ? _raw_read_unlock+0x18/0x30[ 135.282704] ext4_map_blocks+0x294/0x5a0[ 135.283745] ? xa_load+0x6f/0xa0[ 135.284562] ext4_mpage_readpages+0x3d6/0x770[ 135.285646] read_pages+0x67/0x1d0[ 135.286492] ? folio_add_lru+0x51/0x80[ 135.287441] page_cache_ra_unbounded+0x124/0x170[ 135.288510] filemap_get_pages+0x23d/0x5a0[ 135.289457] ? path_openat+0xa72/0xdd0[ 135.290332] filemap_read+0xbf/0x300[ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40[ 135.292192] new_sync_read+0x103/0x170[ 135.293014] vfs_read+0x15d/0x180[ 135.293745] ksys_read+0xa1/0xe0[ 135.294461] do_syscall_64+0x3c/0x80[ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0This patch simply adds an extra check in __ext4_ext_check(), verifying thateh_entries is not 0 when eh_depth is > 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroupFix Oops in dasd_alias_get_start_dev() function caused by the pavgrouppointer being NULL.The pavgroup pointer is checked on the entrance of the function butwithout the lcu->lock being held. Therefore there is a race windowbetween dasd_alias_get_start_dev() and _lcu_update() which setspavgroup to NULL with the lcu->lock held.Fix by checking the pavgroup pointer with lcu->lock held.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix hang during unmount when stopping a space reclaim workerOften when running generic/562 from fstests we can hang during unmount,resulting in a trace like this: Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0 Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530 Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140 Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30 Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0 Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170 Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0 Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120 Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30 Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs] Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0 Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160 Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0 Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0 Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40 Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90 Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0 Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 Sep 07 11:55:32 debian9 kernel: What happens is the following:1) The cleaner kthread tries to start a transaction to delete an unused block group, but the metadata reservation can not be satisfied right away, so a reservation ticket is created and it starts the async metadata reclaim task (fs_info->async_reclaim_work);2) Writeback for all the filler inodes with an i_size of 2K starts (generic/562 creates a lot of 2K files with the goal of filling metadata space). We try to create an inline extent for them, but we fail when trying to insert the inline extent with -ENOSPC (at cow_file_range_inline()) - since this is not critical, we fallback to non-inline mode (back to cow_file_range()), reserve extents---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix kernel crash during module removalThe driver incorrectly frees client instance and subsequenti40e module removal leads to kernel crash.Reproducer:1. Do ethtool offline test followed immediately by another onehost# ethtool -t eth0 offline; ethtool -t eth0 offline2. Remove recursively irdma module that also removes i40e modulehost# modprobe -r irdmaResult:[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030[ 8687.768755] #PF: supervisor read access in kernel mode[ 8687.773895] #PF: error_code(0x0000) - not-present page[ 8687.779034] PGD 0 P4D 0[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e][ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008[ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000[ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 8687.905572] PKRU: 55555554[ 8687.908286] Call Trace:[ 8687.910737] [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e][ 8687.917040] pci_device_remove+0x33/0xa0[ 8687.920962] device_release_driver_internal+0x1aa/0x230[ 8687.926188] driver_detach+0x44/0x90[ 8687.929770] bus_remove_driver+0x55/0xe0[ 8687.933693] pci_unregister_driver+0x2a/0xb0[ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]Two offline tests cause IRDMA driver failure (ETIMEDOUT) and thisfailure is indicated back to i40e_client_subtask() that callsi40e_client_del_instance() to free client instance referencedby pf->cinst and sets this pointer to NULL. During the moduleremoval i40e_remove() calls i40e_lan_del_device() that dereferencespf->cinst that is NULL -> crash.Do not remove client instance when client open callbacks fails andjust clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needsto take care about this situation (when netdev is up and clientis NOT opened) in i40e_notify_client_of_netdev_close() andcalls client close callback only when __I40E_CLIENT_INSTANCE_OPENEDis set.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix use-after-free warningFix the following use-after-free warning which is observed duringcontroller reset:refcount_t: underflow; use-after-free.WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: add a force flush to delay work when radeonAlthough radeon card fence and wait for gpu to finish processing current batch rings,there is still a corner case that radeon lockup work queue may not be fully flushed,and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() toput device in D3hot state.Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.> Configuration and Message requests are the only TLPs accepted by a Function in> the D3hot state. All other received Requests must be handled as Unsupported Requests,> and all received Completions may optionally be handled as Unexpected Completions.This issue will happen in following logs:Unable to handle kernel paging request at virtual address 00008800e0008010CPU 0 kworker/0:3(131): Oops 0pc = [] ra = [] ps = 0000 Tainted: G Wpc is at si_gpu_check_soft_reset+0x3c/0x240ra is at si_dma_is_lockup+0x34/0xd0v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000s6 = fff00007ef07bd98a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000gp = ffffffff81d89690 sp = 00000000aa814126Disabling lock debugging due to kernel taintTrace:[] si_dma_is_lockup+0x34/0xd0[] radeon_fence_check_lockup+0xd0/0x290[] process_one_work+0x280/0x550[] worker_thread+0x70/0x7c0[] worker_thread+0x130/0x7c0[] kthread+0x200/0x210[] worker_thread+0x0/0x7c0[] kthread+0x14c/0x210[] ret_from_kernel_thread+0x18/0x20[] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21So force lockup work queue flush to fix this problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix a possible null pointer dereferenceIn radeon_fp_native_mode(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.The failure status of drm_cvt_mode() on the other path is checked too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix off by one in BIOS boundary checkingBounds checking when parsing init scripts embedded in the BIOS rejectaccess to the last byte. This causes driver initialization to fail onApple eMac's with GeForce 2 MX GPUs, leaving the system with no workingconsole.This is probably only seen on OpenFirmware machines like PowerPC Macsbecause the BIOS image provided by OF is only the used parts of the ROM,not a power-of-two blocks read from PCI directly so PCs always haveempty bytes at the end that are never accessed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()We don't currently validate that the values being set are within the rangewe advertised to userspace as being valid, do so and reject any valuesthat are out of range.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: fix double free of cond_list on error pathsOn error path from cond_read_list() and duplicate_policydb_cond_list()the cond_list_destroy() gets called a second time in caller functions,resulting in NULL pointer deref. Fix this by resetting thecond_list_len to 0 in cond_list_destroy(), making subsequent calls anoop.Also consistently reset the cond_list pointer to NULL after freeing.[PM: fix line lengths in the description]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()While looking at one unrelated syzbot bug, I found the replay logicin __rtnl_newlink() to potentially trigger use-after-free.It is better to clear master_dev and m_ops inside the loop,in case we have to replay it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: amd-xgbe: Fix skb data length underflowThere will be BUG_ON() triggered in include/linux/skbuff.h leading tointermittent kernel panic, when the skb length underflow is detected.Fix this by dropping the packet if such length underflows are seenbecause of inconsistencies in the hardware descriptors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phylib: fix potential use-after-freeCommit bafbdd527d56 ("phylib: Add device reset GPIO support") added callto phy_device_reset(phydev) after the put_device() call in phy_detach().The comment before the put_device() call says that the phydev might goaway with put_device().Fix potential use-after-free by calling phy_device_reset() beforeput_device().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instructionThe illegal instruction turned out to be 'ldbrx' emitted forBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use ofthe same and implement an alternative approach for older processors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dsi: invalid parameter check in msm_dsi_phy_enableThe function performs a check on the "phy" input parameter, however, itis used before the check.Initialize the "dev" variable after the sanity check to avoid a possibleNULL pointer dereference.Addresses-Coverity-ID: 1493860 ("Null pointer dereference")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()The bnx2fc_destroy() functions are removing the interface before callingdestroy_work. This results multiple WARNings from sysfs_remove_group() asthe controller rport device attributes are removed too early.Replace the fcoe_port's destroy_work queue. It's not needed.The problem is easily reproducible with the following steps.Example: $ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? set_kthread_struct+0x40/0x40 [ 584.662909] ret_from_fork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdevstruct rpmsg_ctrldev contains a struct cdev. The current code freesthe rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but thecdev is a managed object, therefore its release is not predictableand the rpmsg_ctrldev could be freed before the cdev is entirelyreleased, as in the backtrace below.[ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c[ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0[ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v[ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26[ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)[ 93.730055] Workqueue: events kobject_delayed_cleanup[ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)[ 93.740216] pc : debug_print_object+0x13c/0x1b0[ 93.744890] lr : debug_print_object+0x13c/0x1b0[ 93.749555] sp : ffffffacf5bc7940[ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000[ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000[ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000[ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0[ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0[ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0[ 93.785814] x17: 0000000000000000 x16: dfffffd000000000[ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c[ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000[ 93.802244] x11: 0000000000000001 x10: 0000000000000000[ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900[ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000[ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000[ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001[ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061[ 93.835104] Call trace:[ 93.837644] debug_print_object+0x13c/0x1b0[ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0[ 93.846987] debug_check_no_obj_freed+0x18/0x20[ 93.851669] slab_free_freelist_hook+0xbc/0x1e4[ 93.856346] kfree+0xfc/0x2f4[ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8[ 93.864445] device_release+0x84/0x168[ 93.868310] kobject_cleanup+0x12c/0x298[ 93.872356] kobject_delayed_cleanup+0x10/0x18[ 93.876948] process_one_work+0x578/0x92c[ 93.881086] worker_thread+0x804/0xcf8[ 93.884963] kthread+0x2a8/0x314[ 93.888303] ret_from_fork+0x10/0x18The cdev_device_add/del() API was created to address this issue (seecommit '233ed09d7fda ("chardev: add helper function to register chardevs with a struct device")'), use it instead of cdev add/del().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix hang in usb_kill_urb by adding memory barriersThe syzbot fuzzer has identified a bug in which processes hang waitingfor usb_kill_urb() to return. It turns out the issue is not unlinkingthe URB; that works just fine. Rather, the problem arises when thewakeup notification that the URB has completed is not received.The reason is memory-access ordering on SMP systems. In outline form,usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently ondifferent CPUs perform the following actions:CPU 0 CPU 1---------------------------- ---------------------------------usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue);Confining your attention to urb->reject and urb->use_count, you cansee that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count;whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject.This pattern is referred to in memory-model circles as SB (for "StoreBuffering"), and it is well known that without suitable enforcement ofthe desired order of accesses -- in the form of memory barriers -- itis entirely possible for one or both CPUs to execute their reads aheadof their writes. The end result will be that sometimes CPU 0 sees theold un-decremented value of urb->use_count while CPU 1 sees the oldun-incremented value of urb->reject. Consequently CPU 0 ends up onthe wait queue and never gets woken up, leading to the observed hangin usb_kill_urb().The same pattern of accesses occurs in usb_poison_urb() and thefailure pathway of usb_hcd_submit_urb().The problem is fixed by adding suitable memory barriers. To provideproper memory-access ordering in the SB pattern, a full barrier isrequired on both CPUs. The atomic_inc() and atomic_dec() accessesthemselves don't provide any memory ordering, but since they arepresent, we can use the optimized smp_mb__after_atomic() memorybarrier in the various routines to obtain the desired effect.This patch adds the necessary memory barriers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci-plat: fix crash when suspend if remote wake enableCrashed at i.mx8qm platform when suspend if enable remote wakeupInternal error: synchronous external abort: 96000210 [#1] PREEMPT SMPModules linked in:CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12Hardware name: Freescale i.MX8QM MEK (DT)Workqueue: events_unbound async_run_entry_fnpstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8sp : ffff80001394bbf0x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29cx2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620Call trace: xhci_disable_hub_port_wake.isra.62+0x60/0xf8 xhci_suspend+0x58/0x510 xhci_plat_suspend+0x50/0x78 platform_pm_suspend+0x2c/0x78 dpm_run_callback.isra.25+0x50/0xe8 __device_suspend+0x108/0x3c0The basic flow: 1. run time suspend call xhci_suspend, xhci parent devices gate the clock. 2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend 3. xhci_suspend call xhci_disable_hub_port_wake, which access register, but clock already gated by run time suspend.This problem was hidden by power domain driver, which call run time resume before it.But the below commit remove it and make this issue happen. commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")This patch call run time resume before suspend to make sure clock is onbefore access register.Testeb-by: Abel Vesa
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: lgdt3306a: Add a check against null-pointer-defThe driver should check whether the client provides the platform_data.The following log reveals it:[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414[ 29.612820] Call Trace:[ 29.613030] [ 29.613201] dump_stack_lvl+0x56/0x6f[ 29.613496] ? kmemdup+0x30/0x40[ 29.613754] print_report.cold+0x494/0x6b7[ 29.614082] ? kmemdup+0x30/0x40[ 29.614340] kasan_report+0x8a/0x190[ 29.614628] ? kmemdup+0x30/0x40[ 29.614888] kasan_check_range+0x14d/0x1d0[ 29.615213] memcpy+0x20/0x60[ 29.615454] kmemdup+0x30/0x40[ 29.615700] lgdt3306a_probe+0x52/0x310[ 29.616339] i2c_device_probe+0x951/0xa90
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix a memleak when uncloning an skb dst and its metadataWhen uncloning an skb dst and its associated metadata, a newdst+metadata is allocated and later replaces the old one in the skb.This is helpful to have a non-shared dst+metadata attached to a specificskb.The issue is the uncloned dst+metadata is initialized with a refcount of1, which is increased to 2 before attaching it to the skb. Whentun_dst_unclone returns, the dst+metadata is only referenced from asingle place (the skb) while its refcount is 2. Its refcount will neverdrop to 0 (when the skb is consumed), leading to a memory leak.Fix this by removing the call to dst_hold in tun_dst_unclone, as thedst+metadata refcount is already 1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure pathip[6]mr_free_table() can only be called under RTNL lock.RTNL: assertion failed at net/core/dev.c (10367)WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Modules linked in:CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 eeRSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfeceRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f4ab89f9059Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: don't release napi in __ibmvnic_open()If __ibmvnic_open() encounters an error such as when setting link state,it calls release_resources() which frees the napi structures needlessly.Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.disable napi and irqs) and leave the rest to the callers.If caller of __ibmvnic_open() is ibmvnic_open(), it should release theresources immediately. If the caller is do_reset() or do_hard_reset(),they will release the resources on the next reset.This fixes following crash that occurred when running the drmgr commandseveral times to add/remove a vnic interface: [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Replenished 8 pools Kernel attempted to read user page (10) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000a3c840 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries ... CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1 Workqueue: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Call Trace: [c0000000548e3a80] [0000000000000006] 0x6 (unreliable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 f9010020 60420000 e9210020 ---[ end trace 5f8033b08fd27706 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Fix deadlock on DSI device attach errorDSI device attach to DSI host will be done with host device's lockheld.Un-registering host in "device attach" error path (ex: probe retry)will result in deadlock with below call trace and non operationalDSI display.Startup Call trace:[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8[ 35.043048] mutex_lock_nested+0x7c/0xc8[ 35.043060] device_del+0x4c/0x3e8[ 35.043075] device_unregister+0x20/0x40[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28[ 35.043093] device_for_each_child+0x68/0xb0[ 35.043105] mipi_dsi_host_unregister+0x40/0x90[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4][ 35.043199] mipi_dsi_attach+0x30/0x48[ 35.043209] tc358762_probe+0x128/0x164 [tc358762][ 35.043225] mipi_dsi_drv_probe+0x28/0x38[ 35.043234] really_probe+0xc0/0x318[ 35.043244] __driver_probe_device+0x80/0xe8[ 35.043254] driver_probe_device+0xb8/0x118[ 35.043263] __device_attach_driver+0x98/0xe8[ 35.043273] bus_for_each_drv+0x84/0xd8[ 35.043281] __device_attach+0xf0/0x150[ 35.043290] device_initial_probe+0x1c/0x28[ 35.043300] bus_probe_device+0xa4/0xb0[ 35.043308] deferred_probe_work_func+0xa0/0xe0[ 35.043318] process_one_work+0x254/0x700[ 35.043330] worker_thread+0x4c/0x448[ 35.043339] kthread+0x19c/0x1a8[ 35.043348] ret_from_fork+0x10/0x20Shutdown Call trace:[ 365.565417] Call trace:[ 365.565423] __switch_to+0x148/0x200[ 365.565452] __schedule+0x340/0x9c8[ 365.565467] schedule+0x48/0x110[ 365.565479] schedule_timeout+0x3b0/0x448[ 365.565496] wait_for_completion+0xac/0x138[ 365.565509] __flush_work+0x218/0x4e0[ 365.565523] flush_work+0x1c/0x28[ 365.565536] wait_for_device_probe+0x68/0x158[ 365.565550] device_shutdown+0x24/0x348[ 365.565561] kernel_restart_prepare+0x40/0x50[ 365.565578] kernel_restart+0x20/0x70[ 365.565591] __do_sys_reboot+0x10c/0x220[ 365.565605] __arm64_sys_reboot+0x2c/0x38[ 365.565619] invoke_syscall+0x4c/0x110[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120[ 365.565648] do_el0_svc+0x2c/0x90[ 365.565661] el0_svc+0x4c/0xf0[ 365.565671] el0t_64_sync_handler+0x90/0xb8[ 365.565682] el0t_64_sync+0x180/0x184
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix the behavior of READ near OFFSET_MAXDan Aloni reports:> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to> the RPC read layers") on the client, a read of 0xfff is aligned up> to server rsize of 0x1000.>> As a result, in a test where the server has a file of size> 0x7fffffffffffffff, and the client tries to read from the offset> 0x7ffffffffffff000, the read causes loff_t overflow in the server> and it returns an NFS code of EINVAL to the client. The client as> a result indefinitely retries the request.The Linux NFS client does not handle NFS?ERR_INVAL, even though allNFS specifications permit servers to return that status code for aREAD.Instead of NFS?ERR_INVAL, have out-of-range READ requests succeedand return a short result. Set the EOF flag in the result to preventthe client from retrying the READ request. This behavior appears tobe consistent with Solaris NFS servers.Note that NFSv3 and NFSv4 use u64 offset values on the wire. Thesemust be converted to loff_t internally before use -- an implicittype cast is not adequate for this purpose. Otherwise VFS checksagainst sb->s_maxbytes do not work properly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix ia_size underflowiattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 andNFSv4 both define file size as an unsigned 64-bit type. Thus thereis a range of valid file size values an NFS client can send that isalready larger than Linux can handle.Currently decode_fattr4() dumps a full u64 value into ia_size. Ifthat value happens to be larger than S64_MAX, then ia_sizeunderflows. I'm about to fix up the NFSv3 behavior as well, so let'scatch the underflow in the common code path: nfsd_setattr().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizesiattr::ia_size is a loff_t, so these NFSv3 procedures must becareful to deal with incoming client size values that are largerthan s64_max without corrupting the value.Silently capping the value results in storing a different valuethan the client passed in which is unexpected behavior, so removethe min_t() check in decode_sattr3().Note that RFC 1813 permits only the WRITE procedure to returnNFS3ERR_FBIG. We believe that NFSv3 reference implementationsalso return NFS3ERR_FBIG when ia_size is too large.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: aiptek - properly check endpoint typeSyzbot reported warning in usb_submit_urb() which is caused by wrongendpoint type. There was a check for the number of endpoints, but notfor the type of endpoint.Fix it by replacing old desc.bNumEndpoints check withusb_find_common_endpoints() helper for finding endpointsFail log:usb 5-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014Workqueue: usb_hub_wq hub_event...Call Trace: aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix slab-out-of-bounds access in packet_recvmsg()syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESHand mmap operations, tpacket_rcv() is queueing skbs withgarbage in skb->cb[], triggering a too big copy [1]Presumably, users of af_packet using mmap() already gets correctmetadata from the mapped buffer, we can simply make sureto clear 12 bytes that might be copied to user space later.BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [inline] packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7fdfd5954c29Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002fRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000dR10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246this frame has 1 object: [32, 160) 'addr'Memory state around the buggy address: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00>ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00==================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:swiotlb: fix info leak with DMA_FROM_DEVICEThe problem I'm addressing was discovered by the LTP test coveringcve-2018-1000204.A short description of what happens follows:1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device.2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO.3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV).4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer.5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails.One can argue that this is an swiotlb problem, because without swiotlbwe leak all zeros, and the swiotlb should be transparent in a sense thatit does not affect the outcome (if all other participants are wellbehaved).Copying the content of the original buffer into the swiotlb buffer isthe only way I can think of to make swiotlb transparent in suchscenarios. So let's do just that if in doubt, but allow the driverto tell us that the whole mapped buffer is going to be overwritten,in which case we can preserve the old behavior and avoid the performanceimpact of the extra bounce.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix kernel-infoleak for SCTP socketssyzbot reported a kernel infoleak [1] of 4 bytes.After analysis, it turned out r->idiag_expires is not initializedif inet_sctp_diag_fill() calls inet_diag_msg_common_fill()Make sure to clear idiag_timer/idiag_retrans/idiag_expiresand let inet_diag_msg_sctpasoc_fill() fill them again if needed.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeBytes 68-71 of 2508 are uninitializedMemory access of size 2508 starts at ffff888114f9b000Data copied to user address 00007f7fe09ff2e0CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: port100: fix use-after-free in port100_send_completeSyzbot reported UAF in port100_send_complete(). The root case is inmissing usb_kill_urb() calls on error handling path of ->probe function.port100_send_complete() accesses devm allocated memory which will befreed on probe failure. We should kill this urbs before returning anerror from probe function to prevent reported use-after-freeFail log:BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26...Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670...Allocated by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:436 [inline] ____kasan_kmalloc mm/kasan/common.c:515 [inline] ____kasan_kmalloc mm/kasan/common.c:474 [inline] __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524 alloc_dr drivers/base/devres.c:116 [inline] devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823 devm_kzalloc include/linux/device.h:209 [inline] port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502Freed by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328 kasan_slab_free include/linux/kasan.h:236 [inline] __cache_free mm/slab.c:3437 [inline] kfree+0xf8/0x2b0 mm/slab.c:3794 release_nodes+0x112/0x1a0 drivers/base/devres.c:501 devres_release_all+0x114/0x190 drivers/base/devres.c:530 really_probe+0x626/0xcc0 drivers/base/dd.c:670
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethernet: Fix error handling in xemaclite_of_probeThis node pointer is returned by of_parse_phandle() with refcountincremented in this function. Calling of_node_put() to avoid therefcount leak. As the remove function do.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix kernel panic when enabling bearerWhen enabling a bearer on a node, a kernel panic is observed:[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]...[ 4.520030] Call Trace:[ 4.520689] [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc][ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc][ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc][ 4.525292] tipc_rcv+0x5da/0x730 [tipc][ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc][ 4.528737] __netif_receive_skb_list_core+0x20b/0x260[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0[ 4.531450] ? dev_gro_receive+0x4c2/0x680[ 4.532512] napi_complete_done+0x6f/0x180[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]...The node in question is receiving activate messages in anotherthread after changing bearer status to allow message sending/receiving in current thread: thread 1 | thread 2 -------- | -------- |tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } |Monitoring pointer in thread 2 is dereferenced before monitoring datais allocated in thread 1. This causes kernel panic.This commit fixes it by allocating the monitoring data before enablingthe bearer to receive messages.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbe: fix pci device refcount leakAs the comment of pci_get_domain_bus_and_slot() says, itreturns a PCI device with refcount incremented, when finishusing it, the caller must decrement the reference count bycalling pci_dev_put().In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),pci_dev_put() is called to avoid leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/virtio: Fix GEM handle creation UAFUserspace can guess the handle value and try to race GEM object creationwith handle close, resulting in a use-after-free if we dereference theobject after dropping the handle's reference. For that reason, droppingthe handle's reference must be done *after* we are done dereferencingthe object.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: get rid of warning on transaction commit when using flushoncommitWhen using the flushoncommit mount option, during almost every transactioncommit we trigger a warning from __writeback_inodes_sb_nr(): $ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)The trace produced in dmesg looks like the following: [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]---This is because we started using writeback_inodes_sb() to flush delallocwhen committing a transaction (when using -o flushoncommit), in order toavoid deadlocks with filesystem freeze operations. This change was madeby commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_rootsin flushoncommit"). After that change we started producing that warning,and every now and then a user reports this since the warning happens toooften, it spams dmesg/syslog, and a user is unsure if this reflects anyproblem that might compromise the filesystem's reliability.We can not just lock the sb->s_umount semaphore before callingwriteback_inodes_sb(), because that would at least deadlock withfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()is called while we are holding that semaphore in write mode, and that cantrigger a transaction commit, resulting in a deadlock. It would alsotrigger the same type of deadlock in the unmount path. Possibly, it couldalso introduce some other locking dependencies that lockdep would report.To fix this call try_to_writeback_inodes_sb() instead ofwriteback_inodes_sb(), because that will try to read lock sb->s_umountand then will only call writeback_inodes_sb() if it was able to lock it.This is fine because the cases where it can't read lock sb->s_umountare during a filesystem unmount or during a filesystem freeze - in thosecases sb->s_umount is write locked and sync_filesystem() is called, whichcalls writeback_inodes_sb(). In other words, in all cases where we can'ttake a read lock on sb->s_umount, writeback is already being triggeredelsewhere.An alternative would be to call btrfs_start_delalloc_roots() with anumber of pages different from LONG_MAX, for example matching the numberof delalloc bytes we currently have, in ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Do not change route.addr.src_addr outside state checksIf the state is not idle then resolve_prepare_src() should immediatelyfail and no change to global state should happen. However, itunconditionally overwrites the src_addr trying to build a temporary anyaddress.For instance if the state is already RDMA_CM_LISTEN then this will corruptthe src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)Which would manifest as this trace from syzkaller: BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xaeThis is indicating that an rdma_id_private was destroyed without doingcma_cancel_listens().Instead of trying to re-use the src_addr memory to indirectly create anany address derived from the dst build one explicitly on the stack andbind to that as any other normal flow would do. rdma_bind_addr() will copyit over the src_addr once it knows the state is valid.This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not changeroute.addr.src_addr.ss_family")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/ib_srp: Fix a deadlockRemove the flush_workqueue(system_long_wq) call since flushingsystem_long_wq is deadlock-prone and since that call is redundant with apreceding cancel_work_sync()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:configfs: fix a race in configfs_{,un}register_subsystem()When configfs_register_subsystem() or configfs_unregister_subsystem()is executing link_group() or unlink_group(),it is possible that two processes add or delete list concurrently.Some unfortunate interleavings of them can cause kernel panic.One of cases is:A --> B --> C --> DA <-- B <-- C <-- D delete list_head *B | delete list_head *C--------------------------------|-----------------------------------configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = nextFix this by adding mutex when calling link_group() or unlink_group(),but parent configfs_subsystem is NULL when config_item is root.So I create a mutex configfs_subsystem_mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Fix preallocation discarding at indirect extent boundaryWhen preallocation extent is the first one in the extent block, thecode would corrupt extent tree header instead. Fix the problem and useudf_delete_aext() for deleting extent to avoid some code duplication.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix u8 overflowBy keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increasesmultiple times and eventually it will wrap around the maximum number(i.e., 255).This patch prevents this by adding a boundary check withL2CAP_MAX_CONF_RSPBtmon log:Bluetooth monitor ver 5.64= Note: Linux version 6.1.0-rc2 (x86_64) 0.264594= Note: Bluetooth subsystem version 2.22 0.264636@ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191= New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604@ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741= Open Index: 00:00:00:00:00:00 [hci0] 13.900426(...)> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............> ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......= bluetoothd: Bluetooth daemon 5.43 14.401828> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Initialize mailbox message for VF resetWhen a MAC address is not assigned to the VF, that portion of the messagesent to the VF is not set. The memory, however, is allocated from thestack meaning that information may be leaked to the VM. Initialize themessage buffer to 0 so that no information is passed to the VM in thiscase.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()The bounds checks in snd_soc_put_volsw_sx() are only being applied to thefirst channel, meaning it is possible to write out of bounds values to thesecond channel in stereo controls. Add appropriate checks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtc: cmos: Fix event handler registration ordering issueBecause acpi_install_fixed_event_handler() enables the eventautomatically on success, it is incorrect to call it before thehandler routine passed to it is ready to handle events.Unfortunately, the rtc-cmos driver does exactly the incorrect thingby calling cmos_wake_setup(), which passes rtc_handler() toacpi_install_fixed_event_handler(), before cmos_do_probe(), becausertc_handler() uses dev_get_drvdata() to get to the cmos objectpointer and the driver data pointer is only populated incmos_do_probe().This leads to a NULL pointer dereference in rtc_handler() on bootif the RTC fixed event happens to be active at the init time.To address this issue, change the initialization ordering of thedriver so that cmos_wake_setup() is always called after a successfulcmos_do_probe() call.While at it, change cmos_pnp_probe() to call cmos_do_probe() afterthe initial if () statement used for computing the IRQ argument tobe passed to cmos_do_probe() which is cleaner than calling it ineach branch of that if () (local variable "irq" can be of type int,because it is passed to that function as an argument of type int).Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not checkACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger numberof systems, because previously it only affected systems withACPI_FADT_LOW_POWER_S0 set, but it is present regardless of thatcommit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethernet: aeroflex: fix potential skb leak in greth_init_rings()The greth_init_rings() function won't free the newly allocated skb whendma_mapping_error() returns error, so add dev_kfree_skb() to fix it.Compile tested only.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: Fix NULL sring after live migrationA NAPI is setup for each network sring to poll data to kernelThe sring with source host is destroyed before live migration andnew sring with target host is setup after live migration.The NAPI for the old sring is not deleted until setup new sringwith target host after migration. With busy_poll/busy_read enabled,the NAPI can be polled before got deleted when resume VM.BUG: unable to handle kernel NULL pointer dereference at0000000000000008IP: xennet_poll+0xae/0xd20PGD 0 P4D 0Oops: 0000 [#1] SMP PTICall Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6...RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900CR2: 0000000000000008---[ end trace f8601785b354351c ]---xen frontend should remove the NAPIs for the old srings before livemigration as the bond srings are destroyedThere is a tiny window between the srings are set to NULL andthe NAPIs are disabled, It is safe as the NAPI threads are stillfrozen at that time
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix not cleanup led when bt_init failsbt_init() calls bt_leds_init() to register led, but if it fails later,bt_leds_cleanup() is not called to unregister it.This can cause panic if the argument "bluetooth-power" in text is freedand then another led_trigger_register() tries to access it:BUG: unable to handle page fault for address: ffffffffc06d3bc0RIP: 0010:strcmp+0xc/0x30 Call Trace: led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()Kernel fault injection test reports null-ptr-deref as follows:BUG: kernel NULL pointer dereference, address: 0000000000000008RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114Call Trace: raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316ieee802154_if_add() allocates wpan_dev as netdev's private data, but notinit the list in struct wpan_dev. cfg802154_netdev_notifier_call() managethe list when device register/unregister, and may lead to null-ptr-deref.Use INIT_LIST_HEAD() on it to initialize it correctly.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix race on per-CQ variable napi work_doneAfter calling napi_complete_done(), the NAPIF_STATE_SCHED bit may becleared, and another CPU can start napi thread and access per-CQ variable,cq->work_done. If the other thread (for example, from busy_poll) setsit to a value >= budget, this thread will continue to run when it shouldstop, and cause memory corruption and panic.To fix this issue, save the per-CQ work_done variable in a local variablebefore napi_complete_done(), so it won't be corrupted by a possibleconcurrent thread after napi_complete_done().Also, add a flag bit to advertise to the NIC firmware: the NAPI work_donevariable race is fixed, so the driver is able to reliably support featureslike busy_poll.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: soc-pcm: Add NULL check in BE reparentingAdd NULL check in dpcm_be_reparent API, to handlekernel NULL pointer dereference error.The issue occurred in fuzzing test.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Check for null before removing sysfs attrsIf coretemp_add_core() gets an error then pdata->core_data[indx]is already NULL and has been kfreed. Don't pass that tosysfs_remove_group() as that will crash in sysfs_remove_group().[Shortened for readability][91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188[91855.165103] #PF: supervisor read access in kernel mode[91855.194506] #PF: error_code(0x0000) - not-present page[91855.224445] PGD 0 P4D 0[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI...[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80...[91855.796571] Call Trace:[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp][91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp][91855.871107] cpuhp_invoke_callback+0x105/0x4b0[91855.893432] cpuhp_thread_fun+0x8e/0x150...Fix this by checking for NULL first.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it after using to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: fix null-ptr-deref while probe() failedI got a null-ptr-deref report as following when doing fault injection test:BUG: kernel NULL pointer dereference, address: 0000000000000058Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:klist_put+0x2d/0xd0Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0//probe path:phy_device_register() device_add()phy_connect phy_attach_direct() //set device driver probe() //it's failed, driver is not bound device_bind_driver() // probe failed, it's not called//remove path:phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev->drv is not NULL klist_remove() <- knode_driver is not added yet, cause null-ptr-derefIn phy_attach_direct(), after setting the 'dev->driver', probe() fails,device_bind_driver() is not called, so the knode_driver->n_klist is notset, then it causes null-ptr-deref in __device_release_driver() whiledeleting device. Fix this by setting dev->driver to NULL in the errorpath in phy_attach_direct().
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e100: Fix possible use after free in e100_xmit_prepareIn e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, soe100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer willresend the skb. But the skb is already freed, which will cause UAF bugwhen the upper layer resends the skb.Remove the harmful free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix error handling in iavf_init_module()The iavf_init_module() won't destroy workqueue when pci_register_driver()failed. Call destroy_workqueue() when pci_register_driver() failed toprevent the resource leak.Similar to the handling of u132_hcd_init in commit f276e002793c("usb: u132-hcd: fix resource leak")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: Fix resource leak in ixgbevf_init_module()ixgbevf_init_module() won't destroy the workqueue created bycreate_singlethread_workqueue() when pci_register_driver() failed. Adddestroy_workqueue() in fail path to prevent the resource leak.Similar to the handling of u132_hcd_init in commit f276e002793c("usb: u132-hcd: fix resource leak")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() failsSmatch report warning as follows:drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from listIf ibmpex_find_sensors() fails in ibmpex_register_bmc(), data willbe freed, but data->list will not be removed from driver_data.bmc_data,then list traversal may cause UAF.Fix by removeing it from driver_data.bmc_data before free().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Check for potential null return of kmalloc_array()As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference.Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: potential buffer overflow in handling symlinksSmatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max)It's caused because Smatch marks 'link_len' as untrusted since it comesfrom sscanf(). Add a check to ensure that 'link_len' is not larger thanthe size of the 'link_str' buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()dev_name() was called with dev.parent as argument but without toNULL-check it before.Solve this by checking the pointer before the call to dev_name().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix the svc_deferred_event trace classFix a NULL deref crash that occurs when an svc_rqst is deferredwhile the sunrpc tracing subsystem is enabled. svc_revisit() setsdr->xprt to NULL, so it can't be relied upon in the tracepoint toprovide the remote's address.Unfortunately we can't revert the "svc_deferred_class" hunk incommit ece200ddd54b ("sunrpc: Save remote presentation address insvc_xprt for trace events") because there is now a specific checkof event format specifiers for unsafe dereferences. The warningthat check emits is: event svc_defer_recv has unsafe dereference of argument 1A "%pISpc" format specifier with a "struct sockaddr *" is indeedflagged by this check.Instead, take the brute-force approach used by the svcrdma_qp_errortracepoint. Convert the dr::addr field into a presentation addressin the TP_fast_assign() arm of the trace event, and store that asa string. This fix can be backported to -stable kernels.In the meantime, commit c6ced22997ad ("tracing: Update print fmtcheck to handle new __get_sockaddr() macro") is now in v5.18, sothis wonky fix can be replaced with __sockaddr() and friendsproperly during the v5.19 merge window.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:veth: Ensure eth header is in skb's linear partAfter feeding a decapsulated packet to a veth device with act_mirred,skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),which expects at least ETH_HLEN byte of linear data (as__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytesunconditionally).Use pskb_may_pull() to ensure veth_xmit() respects this constraint.kernel BUG at include/linux/skbuff.h:2328!RIP: 0010:eth_type_trans+0xcf/0x140Call Trace: __dev_forward_skb2+0xe3/0x160 veth_xmit+0x6e/0x250 [veth] dev_hard_start_xmit+0xc7/0x200 __dev_queue_xmit+0x47f/0x520 ? skb_ensure_writable+0x85/0xa0 ? skb_mpls_pop+0x98/0x1c0 tcf_mirred_act+0x442/0x47e [act_mirred] tcf_action_exec+0x86/0x140 fl_classify+0x1d8/0x1e0 [cls_flower] ? dma_pte_clear_level+0x129/0x1a0 ? dma_pte_clear_level+0x129/0x1a0 ? prb_fill_curr_block+0x2f/0xc0 ? skb_copy_bits+0x11a/0x220 __tcf_classify+0x58/0x110 tcf_classify_ingress+0x6b/0x140 __netif_receive_skb_core.constprop.0+0x47d/0xfd0 ? __iommu_dma_unmap_swiotlb+0x44/0x90 __netif_receive_skb_one_core+0x3d/0xa0 netif_receive_skb+0x116/0x170 be_process_rx+0x22f/0x330 [be2net] be_poll+0x13c/0x370 [be2net] __napi_poll+0x2a/0x170 net_rx_action+0x22f/0x2f0 __do_softirq+0xca/0x2a8 __irq_exit_rcu+0xc1/0xe0 common_interrupt+0x83/0xa0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3: Fix GICR_CTLR.RWP pollingIt turns out that our polling of RWP is totally wrong when checkingfor it in the redistributors, as we test the *distributor* bit index,whereas it is a different bit number in the RDs... Oopsie boo.This is embarassing. Not only because it is wrong, but also becauseit took *8 years* to notice the blunder...Just fix the damn thing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve overflow the qgroup limitWe use extent_changeset->bytes_changed in qgroup_reserve_data() to recordhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently thebytes_changed is set as "unsigned int", and it will overflow if we try tofallocate a range larger than 4GiB. The result is we reserve less bytesand eventually break the qgroup limit.Unlike regular buffered/direct write, which we use one changeset foreach ordered extent, which can never be larger than 256M. Forfallocate, we use one changeset for the whole range, thus it no longerrespects the 256M per extent limit, and caused the problem.The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNTWhen running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiBSince we have no control of how bytes_changed is used, it's better toset it to u64.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Fix use-after-free bug for mm structUnder certain conditions, such as MPI_Abort, the hfi1 cleanup code mayrepresent the last reference held on the task mm.hfi1_mmu_rb_unregister() then drops the last reference and the mm is freedbefore the final use in hfi1_release_user_pages(). A new task mayallocate the mm structure while it is still being used, resulting inproblems. One manifestation is corruption of the mmap_sem counter leadingto a hang in down_write(). Another is corruption of an mm struct that isin use by another task.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qede: confirm skb is allocated before usingqede_build_skb() assumes build_skb() always works and goes straightto skb_reserve(). However, build_skb() can fail under memory pressure.This results in a kernel panic because the skb to reserve is NULL.Add a check in case build_skb() failed to allocate and return NULL.The NULL return is handled correctly in callers to qede_build_skb().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()The error handling path of the probe releases a resource that is not freedin the remove function. In some cases, a ioremap() must be undone.Add the missing iounmap() call in the remove function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_console: eliminate anonymous module_init & module_exitEliminate anonymous module_init() and module_exit(), which can lead toconfusion or ambiguity when reading System.map, crashes/oops/bugs,or an initcall_debug log.Give each of these init and exit functions unique driver-specificnames to eliminate the anonymous names.Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t initExample 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix memory leak in ceph_readdir when note_last_dentry returns errorReset the last_readdir at the same time, and add a comment explainingwhy we don't free last_readdir when dir_emit returns false.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix inode reference leakage in ceph_get_snapdir()The ceph_get_inode() will search for or insert a new inode into thehash for the given vino, and return a reference to it. If new isnon-NULL, its reference is consumed.We should release the reference when in error handing cases.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix use after free in hci_send_aclThis fixes the following trace caused by receivingHCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del withoutfirst checking if conn->type is in fact AMP_LINK and in case it isdo properly cleanup upper layers with hci_disconn_cfm: ================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Free irq vectors in order for v3 HWIf the driver probe fails to request the channel IRQ or fatal IRQ, thedriver will free the IRQ vectors before freeing the IRQs in free_irq(),and this will cause a kernel BUG like this:------------[ cut here ]------------kernel BUG at drivers/pci/msi.c:369!Internal error: Oops - BUG: 0 [#1] PREEMPT SMPCall trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20---[ end trace b88990335b610c11 ]---So we use devm_add_action() to control the order in which we free thevectors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req()In pm8001_chip_fw_flash_update_build(), ifpm8001_chip_fw_flash_update_build() fails, the struct fw_control_exallocated must be freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix task leak in pm8001_send_abort_all()In pm8001_send_abort_all(), make sure to free the allocated sas taskif pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm ioctl: prevent potential spectre v1 gadgetIt appears like cmd could be a Spectre v1 gadget as it's supplied by auser and used as an array index. Prevent the contents of kernel memoryfrom being leaked to userspace via speculative execution by usingarray_index_nospec.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum: Guard against invalid local portsWhen processing events generated by the device's firmware, the driverprotects itself from events reported for non-existent local ports, butnot for the CPU port (local port 0), which exists, but does not have allthe fields as any local port.This can result in a NULL pointer dereference when trying access'struct mlxsw_sp_port' fields which are not initialized for CPU port.Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")already handled such issue by bailing early when processing a PUDE eventreported for the CPU port.Generalize the approach by moving the check to a common function andmaking use of it in all relevant places.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix memory leak[why]Resource release is needed on the error handling pathto prevent memory leak.[how]Fix this by adding kfree on the error handling path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: fix null ptr deref on hci_sync_conn_complete_evtThis event is just specified for SCO and eSCO link types.On the reception of a HCI_Synchronous_Connection_Complete for a BDADDRof an existing LE connection, LE link type and a status that triggers thesecond case of the packet processing a NULL pointer dereference happens,as conn->link is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: properly check endpoint typeSyzbot reported warning in usb_submit_urb() which is caused by wrongendpoint type. We should check that in endpoint is actually present toprevent this warning.Found pipes are now saved to struct mcba_priv and code uses themdirectly instead of making pipes in place.Fail log:| usb 5-1: BOGUS urb xfer, pipe 3 != type 1| WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502| Modules linked in:| CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014| Workqueue: usb_hub_wq hub_event| RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502| ...| Call Trace:| | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline]| mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858| usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396| call_driver_probe drivers/base/dd.c:517 [inline]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx][ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018[ 12.356356] Call Trace:[ 12.358821] dump_stack_lvl+0x34/0x44[ 12.362514] check_preemption_disabled+0xd9/0xe0[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx][ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx][ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40[ 12.384284] local_pci_probe+0x42/0x80[ 12.390162] ? pci_match_device+0xd7/0x110[ 12.396366] pci_device_probe+0xfd/0x1b0[ 12.402372] really_probe+0x1e7/0x3e0[ 12.408114] __driver_probe_device+0xfe/0x180[ 12.414544] driver_probe_device+0x1e/0x90[ 12.420685] __driver_attach+0xc0/0x1c0[ 12.426536] ? __device_attach_driver+0xe0/0xe0[ 12.433061] ? __device_attach_driver+0xe0/0xe0[ 12.439538] bus_for_each_dev+0x78/0xc0[ 12.445294] bus_add_driver+0x12b/0x1e0[ 12.451021] driver_register+0x8f/0xe0[ 12.456631] ? 0xffffffffc07bc000[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx][ 12.468776] do_one_initcall+0x44/0x200[ 12.474401] ? load_module+0xad3/0xba0[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410[ 12.486268] do_init_module+0x5c/0x280[ 12.491730] __do_sys_init_module+0x12e/0x1b0[ 12.497785] do_syscall_64+0x3b/0x90[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 12.509764] RIP: 0033:0x7f554f73ab2e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fc_remote_port_delete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel: kernel: dump_stack+0x66/0x81kernel: __schedule_bug.cold.90+0x5/0x1dkernel: __schedule+0x7af/0x960kernel: schedule+0x28/0x80kernel: schedule_timeout+0x26d/0x3b0kernel: wait_for_completion+0xb4/0x140kernel: ? wake_up_q+0x70/0x70kernel: __wait_rcu_gp+0x12c/0x160kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]kernel: synchronize_sched+0x6c/0x80kernel: ? call_rcu_bh+0x20/0x20kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]kernel: device_for_each_child+0x54/0x90kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]kernel: __handle_irq_event_percpu+0x40/0x180kernel: handle_irq_event_percpu+0x30/0x80kernel: handle_irq_event+0x36/0x60
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash during module load unload testDuring purex packet handling the driver was incorrectly freeing apre-allocated structure. Fix this by skipping that entry.System crashed with the following stack during a module unload test.Call Trace: sbitmap_init_node+0x7f/0x1e0 sbitmap_queue_init_node+0x24/0x150 blk_mq_init_bitmaps+0x3d/0xa0 blk_mq_init_tags+0x68/0x90 blk_mq_alloc_map_and_rqs+0x44/0x120 blk_mq_alloc_set_map_and_rqs+0x63/0x150 blk_mq_alloc_tag_set+0x11b/0x230 scsi_add_host_with_dma.cold+0x3f/0x245 qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx]Call Trace with slub_debug and debug kernel: kasan_report_invalid_free+0x50/0x80 __kasan_slab_free+0x137/0x150 slab_free_freelist_hook+0xc6/0x190 kfree+0xe8/0x2e0 qla2x00_free_device+0x3bb/0x5d0 [qla2xxx] qla2x00_remove_one+0x668/0xcf0 [qla2xxx]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/tm: Fix more userspace r13 corruptionCommit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes aproblem in treclaim where a SLB miss can occur on thethread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13value, clobbering it with the kernel r13 and ultimately resulting inkernel r13 being stored in ckpt_regs.There is an equivalent problem in trechkpt where the user r13 value isloaded into r13 from chkpt_regs to be recheckpointed, but a SLB misscould occur on ckpt_regs accesses after that, which will result in r13being clobbered with a kernel value and that will get recheckpointed andthen restored to user registers.The same memory page is accessed right before this critical window wherea SLB miss could cause corruption, so hitting the bug requires the SLBentry be removed within a small window of instructions, which ispossible if a SLB related MCE hits there. PAPR also permits thehypervisor to discard this SLB entry (because slb_shadow->persistent isonly set to SLB_NUM_BOLTED) although it's not known whether anyimplementations would do this (KVM does not). So this is an extremelyunlikely bug, only found by inspection.Fix this by also storing user r13 in a temporary location on the kernelstack and don't change the r13 register from kernel r13 until the RI=0critical section that does not fault.The SCRATCH0 change is not strictly part of the fix, it's only used inthe RI=0 section so it does not have the same problem as the previousSCRATCH0 bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not clean up repair bio if submit failsThe submit helper will always run bio_endio() on the bio if it fails tosubmit, so cleaning up the bio just leads to a variety of use-after-freeand NULL pointer dereference bugs because we race with the endiofunction that is cleaning up the bio. Instead just return BLK_STS_OK asthe repair function has to continue to process the rest of the pages,and the endio for the repair bio will do the appropriate cleanup for thepage that it was given.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: don't BUG if someone dirty pages without asking ext4 first[un]pin_user_pages_remote is dirtying pages without properly warningthe file system in advance. A related race was noted by Jan Kara in2018[1]; however, more recently instead of it being a very hard-to-hitrace, it could be reliably triggered by process_vm_writev(2) which wasdiscovered by Syzbot[2].This is technically a bug in mm/gup.c, but arguably ext4 is fragile inthat if some other kernel subsystem dirty pages without properlynotifying the file system using page_mkwrite(), ext4 will BUG, whileother file systems will not BUG (although data will still be lost).So instead of crashing with a BUG, issue a warning (since there may bepotential data loss) and just mark the page as clean to avoidunprivileged denial of service attacks until the problem can beproperly fixed. More discussion and background can be found in thethread starting at [2].[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz[2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM: core: keep irq flags in device_pm_check_callbacks()The function device_pm_check_callbacks() can be called under the spinlock (in the reported case it happens from genpd_add_device() ->dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.However this function uncoditionally uses spin_lock_irq() /spin_unlock_irq(), thus not preserving the CPU flags. Use theirqsave/irqrestore instead.The backtrace for the reference:[ 2.752010] ------------[ cut here ]------------[ 2.756769] raw_local_irq_restore() called with IRQs enabled[ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50[ 2.772338] Modules linked in:[ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684[ 2.781384] Freeing initrd memory: 46024K[ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50[ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50[ 2.785846] sp : ffff80000805b7d0[ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002[ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800[ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00[ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff[ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7[ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8[ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0[ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0[ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000[ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000[ 2.889774] Call trace:[ 2.892290] warn_bogus_irq_restore+0x34/0x50[ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0[ 2.901690] genpd_unlock_spin+0x20/0x30[ 2.905724] genpd_add_device+0x100/0x2d0[ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c[ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190[ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0[ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30[ 2.929102] psci_dt_attach_cpu+0x24/0x90[ 2.933230] psci_cpuidle_probe+0x2d4/0x46c[ 2.937534] platform_probe+0x68/0xe0[ 2.941304] really_probe.part.0+0x9c/0x2fc[ 2.945605] __driver_probe_device+0x98/0x144[ 2.950085] driver_probe_device+0x44/0x15c[ 2.954385] __device_attach_driver+0xb8/0x120[ 2.958950] bus_for_each_drv+0x78/0xd0[ 2.962896] __device_attach+0xd8/0x180[ 2.966843] device_initial_probe+0x14/0x20[ 2.971144] bus_probe_device+0x9c/0xa4[ 2.975092] device_add+0x380/0x88c[ 2.978679] platform_device_add+0x114/0x234[ 2.983067] platform_device_register_full+0x100/0x190[ 2.988344] psci_idle_init+0x6c/0xb0[ 2.992113] do_one_initcall+0x74/0x3a0[ 2.996060] kernel_init_freeable+0x2fc/0x384[ 3.000543] kernel_init+0x28/0x130[ 3.004132] ret_from_fork+0x10/0x20[ 3.007817] irq event stamp: 319826[ 3.011404] hardirqs last enabled at (319825): [] __up_console_sem+0x78/0x84[ 3.020332] hardirqs last disabled at (319826): [] el1_dbg+0x24/0x8c[ 3.028458] softirqs last enabled at (318312): [] _stext+0x410/0x588[ 3.036678] softirqs last disabled at (318299): [] __irq_exit_rcu+0x158/0x174[ 3.045607] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bfq: fix use-after-free in bfq_dispatch_requestKASAN reports a use-after-free report when doing normal scsi-mq test[69832.239032] ==================================================================[69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0[69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155[69832.244656][69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8[69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[69832.249069] Workqueue: kblockd blk_mq_run_work_fn[69832.250022] Call Trace:[69832.250541] dump_stack+0x9b/0xce[69832.251232] ? bfq_dispatch_request+0x1045/0x44b0[69832.252243] print_address_description.constprop.6+0x3e/0x60[69832.253381] ? __cpuidle_text_end+0x5/0x5[69832.254211] ? vprintk_func+0x6b/0x120[69832.254994] ? bfq_dispatch_request+0x1045/0x44b0[69832.255952] ? bfq_dispatch_request+0x1045/0x44b0[69832.256914] kasan_report.cold.9+0x22/0x3a[69832.257753] ? bfq_dispatch_request+0x1045/0x44b0[69832.258755] check_memory_region+0x1c1/0x1e0[69832.260248] bfq_dispatch_request+0x1045/0x44b0[69832.261181] ? bfq_bfqq_expire+0x2440/0x2440[69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170[69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830[69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100[69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0[69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570[69832.267147] ? __switch_to+0x5f4/0xee0[69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140[69832.268946] __blk_mq_run_hw_queue+0xc0/0x270[69832.269840] blk_mq_run_work_fn+0x51/0x60[69832.278170] process_one_work+0x6d4/0xfe0[69832.278984] worker_thread+0x91/0xc80[69832.279726] ? __kthread_parkme+0xb0/0x110[69832.280554] ? process_one_work+0xfe0/0xfe0[69832.281414] kthread+0x32d/0x3f0[69832.282082] ? kthread_park+0x170/0x170[69832.282849] ret_from_fork+0x1f/0x30[69832.283573][69832.283886] Allocated by task 7725:[69832.284599] kasan_save_stack+0x19/0x40[69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0[69832.286350] kmem_cache_alloc_node+0x13f/0x460[69832.287237] bfq_get_queue+0x3d4/0x1140[69832.287993] bfq_get_bfqq_handle_split+0x103/0x510[69832.289015] bfq_init_rq+0x337/0x2d50[69832.289749] bfq_insert_requests+0x304/0x4e10[69832.290634] blk_mq_sched_insert_requests+0x13e/0x390[69832.291629] blk_mq_flush_plug_list+0x4b4/0x760[69832.292538] blk_flush_plug_list+0x2c5/0x480[69832.293392] io_schedule_prepare+0xb2/0xd0[69832.294209] io_schedule_timeout+0x13/0x80[69832.295014] wait_for_common_io.constprop.1+0x13c/0x270[69832.296137] submit_bio_wait+0x103/0x1a0[69832.296932] blkdev_issue_discard+0xe6/0x160[69832.297794] blk_ioctl_discard+0x219/0x290[69832.298614] blkdev_common_ioctl+0x50a/0x1750[69832.304715] blkdev_ioctl+0x470/0x600[69832.305474] block_ioctl+0xde/0x120[69832.306232] vfs_ioctl+0x6c/0xc0[69832.306877] __se_sys_ioctl+0x90/0xa0[69832.307629] do_syscall_64+0x2d/0x40[69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9[69832.309382][69832.309701] Freed by task 155:[69832.310328] kasan_save_stack+0x19/0x40[69832.311121] kasan_set_track+0x1c/0x30[69832.311868] kasan_set_free_info+0x1b/0x30[69832.312699] __kasan_slab_free+0x111/0x160[69832.313524] kmem_cache_free+0x94/0x460[69832.314367] bfq_put_queue+0x582/0x940[69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0[69832.317275] bfq_bfqq_expire+0xb27/0x2440[69832.318084] bfq_dispatch_request+0x697/0x44b0[69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830[69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0[69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140[69832.322225] __blk_mq_run_hw_queue+0xc0/0x270[69832.323114] blk_mq_run_work_fn+0x51/0x6---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memstick/mspro_block: fix handling of read-only devicesUse set_disk_ro to propagate the read-only state to the block layerinstead of checking for it in ->open and leaking a reference in caseof a read-only device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block, bfq: don't move oom_bfqqOur test report a UAF:[ 2073.019181] ==================================================================[ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168[ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584[ 2073.019192][ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5[ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015[ 2073.019200] Call trace:[ 2073.019203] dump_backtrace+0x0/0x310[ 2073.019206] show_stack+0x28/0x38[ 2073.019210] dump_stack+0xec/0x15c[ 2073.019216] print_address_description+0x68/0x2d0[ 2073.019220] kasan_report+0x238/0x2f0[ 2073.019224] __asan_store8+0x88/0xb0[ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168[ 2073.019233] bfq_put_async_queues+0xbc/0x208[ 2073.019236] bfq_pd_offline+0x178/0x238[ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420[ 2073.019244] bfq_exit_queue+0x128/0x178[ 2073.019249] blk_mq_exit_sched+0x12c/0x160[ 2073.019252] elevator_exit+0xc8/0xd0[ 2073.019256] blk_exit_queue+0x50/0x88[ 2073.019259] blk_cleanup_queue+0x228/0x3d8[ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk][ 2073.019274] null_exit+0x90/0x114 [null_blk][ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0[ 2073.019282] el0_svc_common+0xc8/0x320[ 2073.019287] el0_svc_handler+0xf8/0x160[ 2073.019290] el0_svc+0x10/0x218[ 2073.019291][ 2073.019294] Allocated by task 14163:[ 2073.019301] kasan_kmalloc+0xe0/0x190[ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418[ 2073.019308] bfq_pd_alloc+0x54/0x118[ 2073.019313] blkcg_activate_policy+0x250/0x460[ 2073.019317] bfq_create_group_hierarchy+0x38/0x110[ 2073.019321] bfq_init_queue+0x6d0/0x948[ 2073.019325] blk_mq_init_sched+0x1d8/0x390[ 2073.019330] elevator_switch_mq+0x88/0x170[ 2073.019334] elevator_switch+0x140/0x270[ 2073.019338] elv_iosched_store+0x1a4/0x2a0[ 2073.019342] queue_attr_store+0x90/0xe0[ 2073.019348] sysfs_kf_write+0xa8/0xe8[ 2073.019351] kernfs_fop_write+0x1f8/0x378[ 2073.019359] __vfs_write+0xe0/0x360[ 2073.019363] vfs_write+0xf0/0x270[ 2073.019367] ksys_write+0xdc/0x1b8[ 2073.019371] __arm64_sys_write+0x50/0x60[ 2073.019375] el0_svc_common+0xc8/0x320[ 2073.019380] el0_svc_handler+0xf8/0x160[ 2073.019383] el0_svc+0x10/0x218[ 2073.019385][ 2073.019387] Freed by task 72584:[ 2073.019391] __kasan_slab_free+0x120/0x228[ 2073.019394] kasan_slab_free+0x10/0x18[ 2073.019397] kfree+0x94/0x368[ 2073.019400] bfqg_put+0x64/0xb0[ 2073.019404] bfqg_and_blkg_put+0x90/0xb0[ 2073.019408] bfq_put_queue+0x220/0x228[ 2073.019413] __bfq_put_async_bfqq+0x98/0x168[ 2073.019416] bfq_put_async_queues+0xbc/0x208[ 2073.019420] bfq_pd_offline+0x178/0x238[ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420[ 2073.019429] bfq_exit_queue+0x128/0x178[ 2073.019433] blk_mq_exit_sched+0x12c/0x160[ 2073.019437] elevator_exit+0xc8/0xd0[ 2073.019440] blk_exit_queue+0x50/0x88[ 2073.019443] blk_cleanup_queue+0x228/0x3d8[ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk][ 2073.019459] null_exit+0x90/0x114 [null_blk][ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0[ 2073.019467] el0_svc_common+0xc8/0x320[ 2073.019471] el0_svc_handler+0xf8/0x160[ 2073.019474] el0_svc+0x10/0x218[ 2073.019475][ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024[ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)[ 2073.019486] The buggy address belongs to the page:[ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0[ 2073.020123] flags: 0x7ffff0000008100(slab|head)[ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00[ 2073.020409] ra---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add vlan list lock to protect vlan listWhen adding port base VLAN, vf VLAN need to remove from HW and modifythe vlan state in vf VLAN list as false. If the periodicity task isfreeing the same node, it may cause "use after free" error.This patch adds a vlan list lock to protect the vlan list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_regionThe device_node pointer is returned by of_parse_phandle() orof_get_child_by_name() with refcount incremented.We should use of_node_put() on it when done.This function only call of_node_put(node) when of_address_to_resourcesucceeds, missing error cases.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmemmemory"), we could get a resource allocated during boot viaalloc_resource(). And it's required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mxser: fix xmit_buf leak in activate when LSR == 0xffWhen LSR is 0xff in ->activate() (rather unlike), we return an error.Provided ->shutdown() is not called when ->activate() fails, nothingactually frees the buffer in this case.Fix this by properly freeing the buffer in a designated label. We jumpthere also from the "!info->type" if now too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix use after free in remove_phb_dynamic()In remove_phb_dynamic() we use &phb->io_resource, after we've calleddevice_unregister(&host_bridge->dev). But the unregister may have freedphb, because pcibios_free_controller_deferred() is the release functionfor the host_bridge.If there are no outstanding references when we call device_unregister()then phb will be freed out from under us.This has gone mainly unnoticed, but with slub_debug and page_poisonenabled it can lead to a crash: PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168To avoid it, we can take a reference to the host_bridge->dev until we'redone using phb. Then when we drop the reference the phb will be freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: fix race between xmit and resetThere is a race between reset and the transmit paths that can lead toibmvnic_xmit() accessing an scrq after it has been freed in the resetpath. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2cThe immediate cause of the crash is the access of tx_scrq in the followingsnippet during a reset, where the tx_scrq can be either NULL or an addressthat will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... }But beyond that, the call to ibmvnic_xmit() itself is not safe during areset and the reset path attempts to avoid this by stopping the queue inibmvnic_cleanup(). However just after the queue was stopped, an in-flightibmvnic_complete_tx() could have restarted the queue even as the reset isprogressing.Since the queue was restarted we could get a call to ibmvnic_xmit() whichcan then access the bad tx_scrq (or other fields).We cannot however simply have ibmvnic_complete_tx() check the ->resettingbit and skip starting the queue. This can race at the "back-end" of a goodreset which just restarted the queue but has not cleared the ->resettingbit yet. If we skip restarting the queue due to ->resetting being true,the queue would remain stopped indefinitely potentially leading to transmittimeouts.IOW ->resetting is too broad for this purpose. Instead use a new flagthat indicates whether or not the queues are active. Only the open/reset paths control when the queues are active. ibmvnic_complete_tx()and others wake up the queue only if the queue is marked active.So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue();To ensure that ->tx_queues_active and state of the queues are consistent,we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix more uncharged while msg has more_dataIn tcp_bpf_send_verdict(), if msg has more data aftertcp_bpf_sendmsg_redir():tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_allocThe msg->sg.size(11000) has been uncharged twice, to fix we can charge theremaining msg->sg.size before goto more data.This issue can cause the following info:WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix double uncharge the mem of sk_msgIf tcp_bpf_sendmsg is running during a tear down operation, psock may befreed.tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free()The mem of msg has been uncharged in tcp_bpf_send_verdict() bysk_msg_return(), and would be uncharged by sk_msg_free() again. When psockis null, we can simply returning an error code, this would then triggerthe sk_msg_free_nocharge in the error path of __SK_REDIRECT and would havethe side effect of throwing an error up to user space. This would be aslight change in behavior from user side but would look the same as anerror if the redirect on the socket threw an error.This issue can cause the following info:WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is fullIf tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partialmemory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size isgreater than osize after sk_msg_alloc(), memleak occurs. To fix we usesk_msg_trim() to release the allocated memory, then goto wait for memory.Other call paths of sk_msg_alloc() have the similar issue, such astls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),as Cong Wang suggested.This issue can cause the following info:WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_initThe reference counting issue happens in several error handling pathson a refcounted object "nc->dmac". In these paths, the function simplyreturns the error code, forgetting to balance the reference count of"nc->dmac", increased earlier by dma_request_channel(), which maycause refcount leaks.Fix it by decrementing the refcount of specific object in those errorpaths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix reference leak in tegra_dsi_ganged_probeThe reference taken by 'of_find_device_by_node()' must be released whennot needed anymore. Add put_device() call to fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix abort all task initializationIn pm80xx_send_abort_all(), the n_elem field of the ccb used is notinitialized to 0. This missing initialization sometimes lead to the taskcompletion path seeing the ccb with a non-zero n_elem resulting in theexecution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),causing a crash such as:[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280[ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012[ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0[ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0[ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b[ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000[ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000[ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000[ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0[ 197.762656] Call Trace:[ 197.765127] [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx][ 197.772364] ? do_raw_spin_unlock+0x54/0x220[ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx][ 197.782406] process_oq+0xe85/0x7890 [pm80xx][ 197.786817] ? lock_acquire+0x194/0x490[ 197.790697] ? handle_irq_event+0x10e/0x1b0[ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx][ 197.800378] ? __wake_up_bit+0x100/0x100[ 197.804340] ? lock_is_held_type+0x98/0x110[ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx][ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0[ 197.818785] __do_softirq+0x1b5/0x82d[ 197.822485] ? do_raw_spin_unlock+0x54/0x220[ 197.826799] __irq_exit_rcu+0x17e/0x1e0[ 197.830678] irq_exit_rcu+0xa/0x20[ 197.834114] common_interrupt+0x78/0x90[ 197.840051] [ 197.844236] [ 197.848397] asm_common_interrupt+0x1e/0x40Avoid this issue by always initializing the ccb n_elem field to 0 inpm8001_send_abort_all(), pm8001_send_read_log() andpm80xx_send_abort_all().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dax: make sure inodes are flushed before destroy cacheA bug can be triggered by following command$ modprobe nd_pmem && modprobe -r nd_pmem[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)[ 10.062433] Call Trace:[ 10.062673] dump_stack_lvl+0x34/0x44[ 10.062865] slab_err+0x90/0xd0[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0[ 10.063848] kmem_cache_destroy+0x4a/0x110[ 10.064058] __x64_sys_delete_module+0x265/0x300This is caused by dax_fs_exit() not flushing inodes before destroy cache.To fix this issue, call rcu_barrier() before destroy cache.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: asix: add proper error handling of usb read errorsSyzbot once again hit uninit value in asix driver. The problem still thesame -- asix_read_cmd() reads less bytes, than was requested by caller.Since all read requests are performed via asix_read_cmd() let's catchusb related error there and add __must_check notation to be sure allcallers actually check return value.So, this patch adds sanity check inside asix_read_cmd(), that simplychecks if bytes read are not less, than was requested and adds missingerror handling of asix_read_cmd() all across the driver code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()is assigned to mode and is passed to drm_mode_probed_add() directly afterthat. drm_mode_probed_add() passes &mode->head to list_add_tail(), andthere is a dereference of it in list_add_tail() without recoveries, whichcould lead to NULL pointer dereference on failure ofamdgpu_dm_create_common_mode().Fix this by adding a NULL check of mode.This bug was found by a static analyzer.Builds with 'make allyesconfig' show no new warnings,and our static analyzer no longer warns about this code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath9k_htc: fix uninit value bugsSyzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missingfield initialization.In htc_connect_service() svc_meta_len and pad are not initialized. Basedon code it looks like in current skb there is no service data, so simplyinitialize svc_meta_len to 0.htc_issue_send() does not initialize htc_frame_hdr::control array. Basedon firmware code, it will initialize it by itself, so simply zero wholearray to make KMSAN happyFail logs:BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275...Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258...Bytes 4-7 of 18 are uninitializedMemory access of size 18 starts at ffff888027377e00BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275...Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258...Bytes 16-17 of 18 are uninitializedMemory access of size 18 starts at ffff888027377e00
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUEDIf the callback 'start_streaming' fails, then allqueued buffers in the driver should be returned withstate 'VB2_BUF_STATE_QUEUED'. Currently, they arereturned with 'VB2_BUF_STATE_ERROR' which is wrong.Fix this. This also fixes the warning:[ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common][ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6[ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14[ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT)[ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common][ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common][ 65.592395] sp : ffff800012bc3ad0[ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8[ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612[ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0[ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff[ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78[ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce[ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228[ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78[ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880[ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0[ 65.598940] Call trace:[ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common][ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common][ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2][ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2][ 65.601103] v4l_streamon+0x3c/0x50 [videodev][ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev][ 65.601977] video_usercopy+0x320/0x828 [videodev][ 65.602419] video_ioctl2+0x3c/0x58 [videodev][ 65.602830] v4l2_ioctl+0x60/0x90 [videodev][ 65.603227] __arm64_sys_ioctl+0xa8/0xe0[ 65.603576] invoke_syscall+0x54/0x118[ 65.603911] el0_svc_common.constprop.3+0x84/0x100[ 65.604332] do_el0_svc+0x34/0xa0[ 65.604625] el0_svc+0x1c/0x50[ 65.604897] el0t_64_sync_handler+0x88/0xb0[ 65.605264] el0t_64_sync+0x16c/0x170[ 65.605587] ---[ end trace 578e0ba07742170d ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transactionAV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:firewire-lib: Add support for deferred transaction") while 'deferrable'flag can be uninitialized for non-control/notify AV/C transactions.UBSAN reports it:kernel: ================================================================================kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9kernel: load of value 158 is not a valid value for type '_Bool'kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntukernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019kernel: Call Trace:kernel: kernel: show_stack+0x52/0x58kernel: dump_stack_lvl+0x4a/0x5fkernel: dump_stack+0x10/0x12kernel: ubsan_epilogue+0x9/0x45kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]kernel: fcp_response+0x28/0x30 [snd_firewire_lib]kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]kernel: tasklet_action_common.constprop.0+0xea/0xf0kernel: tasklet_action+0x22/0x30kernel: __do_softirq+0xd9/0x2e3kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0kernel: do_softirq+0x75/0xa0kernel: kernel: kernel: __local_bh_enable_ip+0x50/0x60kernel: irq_forced_thread_fn+0x7e/0x90kernel: irq_thread+0xba/0x190kernel: ? irq_thread_fn+0x60/0x60kernel: kthread+0x11e/0x140kernel: ? irq_thread_check_affinity+0xf0/0xf0kernel: ? set_kthread_struct+0x50/0x50kernel: ret_from_fork+0x22/0x30kernel: kernel: ================================================================================This commit fixes the bug. The bug has no disadvantage for the non-control/notify AV/C transactions since the flag has an effect for AV/Cresponse with INTERIM (0x0f) status which is not used for the transactionsin AV/C general specification.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: usb: go7007: s2250-board: fix leak in probe()Call i2c_unregister_device(audio) on this error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: don't delete queue kobject before its childrenkobjects aren't supposed to be deleted before their child kobjects aredeleted. Apparently this is usually benign; however, a WARN will betriggered if one of the child kobjects has a named attribute group: sysfs group 'modes' not found for kobject 'crypto' WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Call Trace: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610Fix this by moving the kobject_del() and the correspondingkobject_uevent() to the correct place.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exec: Force single empty string when argv is emptyQuoting[1] Ariadne Conill:"In several other operating systems, it is a hard requirement that thesecond argument to execve(2) be the name of a program, thus prohibitinga scenario where argc < 1. POSIX 2017 also recommends this behaviour,but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions....Interestingly, Michael Kerrisk opened an issue about this in 2008[3],but there was no consensus to support fixing this issue then.Hopefully now that CVE-2021-4034 shows practical exploitative use[4]of this bug in a shellcode, we can reconsider.This issue is being tracked in the KSPP issue tracker[5]."While the initial code searches[6][7] turned up what appeared to bemostly corner case tests, trying to that just reject argv == NULL(or an immediately terminated pointer list) quickly started tripping[8]existing userspace programs.The next best approach is forcing a single empty string into argv andadjusting argc to match. The number of programs depending on argc == 0seems a smaller set than those calling execve with a NULL argv.Account for the additional stack space in bprm_stack_limits(). Inject anempty string when argc == 0 (and set argc = 1). Warn about the case souserspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string addedAdditionally WARN() and reject NULL argv usage for kernel threads.[1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html[3] https://bugzilla.kernel.org/show_bug.cgi?id=8408[4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt[5] https://github.com/KSPP/linux/issues/176[6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0[7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0[8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent bad output lengths in smb2_ioctl_query_info()When calling smb2_ioctl_query_info() withsmb_query_info::flags=PASSTHRU_FSCTL andsmb_query_info::output_buffer_length=0, the following would return0x10 buffer = memdup_user(arg + sizeof(struct smb_query_info), qi.output_buffer_length); if (IS_ERR(buffer)) { kfree(vars); return PTR_ERR(buffer); }rather than a valid pointer thus making IS_ERR() check fail. Thiswould then cause a NULL ptr deference in @buffer when accessing itlater in smb2_ioctl_query_ioctl(). While at it, prevent having a@buffer smaller than 8 bytes to correctly handle SMB2_SET_INFOFileEndOfFileInformation requests whensmb_query_info::flags=PASSTHRU_SET_INFO.Here is a small C reproducer which triggers a NULL ptr in @buffer whenpassing an invalid smb_query_info::flags #include #include #include #include #include #include #define die(s) perror(s), exit(1) #define QUERY_INFO 0xc018cf07 int main(int argc, char *argv[]) { int fd; if (argc < 2) exit(1); fd = open(argv[1], O_RDONLY); if (fd == -1) die("open"); if (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1) die("ioctl"); close(fd); return 0; } mount.cifs //srv/share /mnt -o ... gcc repro.c && ./a.out /mnt/f0 [ 114.138620] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.139310] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 114.139775] CPU: 2 PID: 995 Comm: a.out Not tainted 5.17.0-rc8 #1 [ 114.140148] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs] [ 114.141221] Code: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24 [ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256 [ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: ffffffffa020580d [ 114.143119] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffa043a380 [ 114.143544] RBP: ffff888115503278 R08: 0000000000000001 R09: 0000000000000003 [ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288 [ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000 [ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:0000000000000000 [ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0 [ 114.146131] Call Trace: [ 114.146291] [ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs] [ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs] [ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs] [ 114.147775] ? dentry_path_raw+0xa6/0xf0 [ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs] [ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs] [ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs] [ 114.149371] ? lock_downgrade+0x6f0/0x6f0 [ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs] [ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0 [ 114.150562] ? __up_read+0x192/0x710 [ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0 [ 114.151025] ? __x64_sys_openat+0x11f/0x1d0 [ 114.151296] __x64_sys_ioctl+0x127/0x190 [ 114.151549] do_syscall_64+0x3b/0x90 [ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 114.152079] RIP: 0033:0x7f7aead043df [ 114.152306] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_locksyzbot caught a potential deadlock between the PCMruntime->buffer_mutex and the mm->mmap_lock. It was brought by therecent fix to cover the racy read/write and other ioctls, and in thatcommit, I overlooked a (hopefully only) corner case that may take therevert lock, namely, the OSS mmap. The OSS mmap operationexceptionally allows to re-configure the parameters inside the OSSmmap syscall, where mm->mmap_mutex is already held. Meanwhile, thecopy_from/to_user calls at read/write operations also take themm->mmap_lock internally, hence it may lead to a AB/BA deadlock.A similar problem was already seen in the past and we fixed it with arefcount (in commit b248371628aa). The former fix covered only thecall paths with OSS read/write and OSS ioctls, while we need to coverthe concurrent access via both ALSA and OSS APIs now.This patch addresses the problem above by replacing the buffer_mutexlock in the read/write operations with a refcount similar as we'veused for OSS. The new field, runtime->buffer_accessing, keeps thenumber of concurrent read/write operations. Unlike the formerbuffer_mutex protection, this protects only around thecopy_from/to_user() calls; the other codes are basically protected bythe PCM stream lock. The refcount can be a negative, meaning blockedby the ioctls. If a negative value is seen, the read/write abortswith -EBUSY. In the ioctl side, OTOH, they check this refcount, too,and set to a negative value for blocking unless it's already beingaccessed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: prevent underflow in nfssvc_decode_writeargs()Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len'Change the type to unsigned to prevent this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix handlecache and multiuserIn multiuser each individual user has their own tcon structure for theshare and thus their own handle for a cached directory.When we umount such a share we much make sure to release the pinned down dentryfor each such tcon and not just the master tcon.Otherwise we will get nasty warnings on umount that dentries are still in use:[ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\ (2) [unmount of cifs cifs]...[ 3459.590492] Call Trace:[ 3459.590500] d_walk+0x61/0x2a0[ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0[ 3459.590526] shrink_dcache_for_umount+0x49/0x110[ 3459.590535] generic_shutdown_super+0x1a/0x110[ 3459.590542] kill_anon_super+0x14/0x30[ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs][ 3459.590773] deactivate_locked_super+0x36/0xa0[ 3459.590782] cleanup_mnt+0x131/0x190[ 3459.590789] task_work_run+0x5c/0x90[ 3459.590798] exit_to_user_mode_loop+0x151/0x160[ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0[ 3459.590818] syscall_exit_to_user_mode+0x12/0x30[ 3459.590828] do_syscall_64+0x48/0x90[ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: use try_get_ops() in tpm-space.cAs part of the series conversion to remove nested TPM operations:https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/exposure of the chip->tpm_mutex was removed from much of the upperlevel code. In this conversion, tpm2_del_space() was missed. Thisdidn't matter much because it's usually called closely after aconverted operation, so there's only a very tiny race window where thechip can be removed before the space flushing is done which causes aNULL deref on the mutex. However, there are reports of this windowbeing hit in practice, so fix this by converting tpm2_del_space() touse tpm_try_get_ops(), which performs all the teardown checks beforeacquring the mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: fix reference counting for struct tpm_chipThe following sequence of operations results in a refcount warning:1. Open device /dev/tpmrm.2. Remove module tpm_tis_spi.3. Write a TPM command to the file descriptor opened at step 1.------------[ cut here ]------------WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4refcount_t: addition on 0; use-after-free.Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmacsha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaesraspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcmsnd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2Hardware name: BCM2711[] (unwind_backtrace) from [] (show_stack+0x10/0x14)[] (show_stack) from [] (dump_stack+0xc4/0xd8)[] (dump_stack) from [] (__warn+0x104/0x108)[] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)[] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4)[] (kobject_get) from [] (tpm_try_get_ops+0x14/0x54 [tpm])[] (tpm_try_get_ops [tpm]) from [] (tpm_common_write+0x38/0x60 [tpm])[] (tpm_common_write [tpm]) from [] (vfs_write+0xc4/0x3c0)[] (vfs_write) from [] (ksys_write+0x58/0xcc)[] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)Exception stack(0xc226bfa8 to 0xc226bff0)bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684bfe0: 0000006c beafe648 0001056c b6eb6944---[ end trace d4b8409def9b8b1f ]---The reason for this warning is the attempt to get the chip->dev referencein tpm_common_write() although the reference counter is already zero.Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") theextra reference used to prevent a premature zero counter is never taken,because the required TPM_CHIP_FLAG_TPM2 flag is never set.Fix this by moving the TPM 2 character device handling fromtpm_chip_alloc() to tpm_add_char_device() which is called at a later pointin time when the flag has been set in case of TPM2.Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")already introduced function tpm_devs_release() to release the extrareference but did not implement the required put on chip->devs that resultsin the call of this function.Fix this by putting chip->devs in tpm_chip_unregister().Finally move the new implementation for the TPM 2 handling into a newfunction to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in thegood case and error cases.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix races among concurrent prealloc proc writesWe have no protection against concurrent PCM buffer preallocationchanges via proc files, and it may potentially lead to UAF or someweird problem. This patch applies the PCM open_mutex to the procwrite operation for avoiding the racy proc writes and the PCM streamopen (and further operations).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: oss: Fix PCM OSS buffer allocation overflowWe've got syzbot reports hitting INT_MAX overflow at vmalloc()allocation that is called from snd_pcm_plug_alloc(). Although weapply the restrictions to input parameters, it's based only on thehw_params of the underlying PCM device. Since the PCM OSS layerallocates a temporary buffer for the data conversion, the size maybecome unexpectedly large when more channels or higher rates is given;in the reported case, it went over INT_MAX, hence it hits WARN_ON().This patch is an attempt to avoid such an overflow and an allocationfor too large buffers. First off, it adds the limit of 1MB as theupper bound for period bytes. This must be large enough for all usecases, and we really don't want to handle a larger temporary bufferthan this size. The size check is performed at two places, where theoriginal period bytes is calculated and where the plugin buffer sizeis calculated.In addition, the driver uses array_size() and array3_size() formultiplications to catch overflows for the converted period size andbuffer bytes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: initialize registers in nft_do_chain()Initialize registers to avoid stack leak into userspace.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check if modulo is 0 before dividing.[How & Why]If a value of 0 is read, then this will cause a divide-by-0 panic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix io hung while disconnecting deviceIn our tests, "qemu-nbd" triggers a io hung:INFO: task qemu-nbd:11445 blocked for more than 368 seconds. Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000Call Trace: __schedule+0x480/0x1050 ? _raw_spin_lock_irqsave+0x3e/0xb0 schedule+0x9c/0x1b0 blk_mq_freeze_queue_wait+0x9d/0xf0 ? ipi_rseq+0x70/0x70 blk_mq_freeze_queue+0x2b/0x40 nbd_add_socket+0x6b/0x270 [nbd] nbd_ioctl+0x383/0x510 [nbd] blkdev_ioctl+0x18e/0x3e0 __x64_sys_ioctl+0xac/0x120 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7fd8ff706577RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000fRBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006dR13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0"qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, followingmessage was found:block nbd0: Send disconnect failed -32Which indicate that something is wrong with the server. Then,"qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clearrequests after commit 2516ab1543fd("nbd: only clear the queue on deviceteardown"). And in the meantime, request can't complete through timeoutbecause nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', whichmeans such request will never be completed in this situation.Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won'tcomplete multiple times, switch back to call nbd_clear_sock() innbd_clear_sock_ioctl(), so that inflight requests can be cleared.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon()ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...We hold ieee->beacon_lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need ieee->beacon_lock in position (2) of thread 2.As a result, ieee80211_beacons_stop() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_irqsave(), which could let timer handler to obtainthe needed lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:extcon: Modify extcon device to be created after driver data is setCurrently, someone can invoke the sysfs such as state_show()intermittently before dev_set_drvdata() is done.And it can be a cause of kernel Oops because of edev is Null at that time.So modified the driver registration to after setting drviver data.- Oops's backtrace.Backtrace:[] (state_show) from [] (dev_attr_show)[] (dev_attr_show) from [] (sysfs_kf_seq_show)[] (sysfs_kf_seq_show) from [] (kernfs_seq_show)[] (kernfs_seq_show) from [] (seq_read)[] (seq_read) from [] (kernfs_fop_read)[] (kernfs_fop_read) from [] (__vfs_read)[] (__vfs_read) from [] (vfs_read)[] (vfs_read) from [] (ksys_read)[] (ksys_read) from [] (sys_read)[] (sys_read) from [] (__sys_trace_return)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: usb: host: Fix deadlock in oxu_bus_suspend()There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action()oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ...We hold oxu->lock in position (1) of thread 1, and usedel_timer_sync() to wait timer to stop, but timer handleralso need oxu->lock in position (2) of thread 2. As a result,oxu_bus_suspend() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_irq(), which could let timer handler to obtainthe needed lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu-v3: check return value after calling platform_get_resource()It will cause null-ptr-deref if platform_get_resource() returns NULL,we need check the return value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data typeIn zynqmp_dma_alloc/free_chan_resources functions there is apotential overflow in the below expressions.dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL);dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p);The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Thoughthis overflow condition is not observed but it is a potential problemin the case of 32-bit multiplication. Hence fix it by changing thedesc_size data type to size_t.In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro indma_alloc_coherent API argument.Addresses-Coverity: Event overflow_before_widen.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xprtrdma: treat all calls not a bcall when bc_serv is NULLWhen a rdma server returns a fault format reply, nfs v3 client maytreats it as a bcall when bc service is not exist.The debug message at rpcrdma_bc_receive_call are,[56579.837169] RPC: rpcrdma_bc_receive_call: callback XID00000001, length=20[56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 04After that, rpcrdma_bc_receive_call will meets NULL pointer as,[ 226.057890] BUG: unable to handle kernel NULL pointer dereference at00000000000000c8...[ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20...[ 226.059732] Call Trace:[ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma][ 226.060011] __ib_process_cq+0x89/0x170 [ib_core][ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core][ 226.060257] process_one_work+0x1a7/0x360[ 226.060367] ? create_worker+0x1a0/0x1a0[ 226.060440] worker_thread+0x30/0x390[ 226.060500] ? create_worker+0x1a0/0x1a0[ 226.060574] kthread+0x116/0x130[ 226.060661] ? kthread_flush_work_fn+0x10/0x10[ 226.060724] ret_from_fork+0x35/0x40...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix sleeping function called from invalid context on RT kernelWhen setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in thecmdline, the output_printk() was called, and the spin_lock_irqsave() was called in theatomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,these locks are replaced with sleepable rt-spinlock, so the stack calltrace willbe triggered.Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_starttp_printk=1" enabled. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()It will cause null-ptr-deref when using 'res', if platform_get_resource()returns NULL, so move using 'res' after devm_ioremap_resource() thatwill check it to avoid null-ptr-deref.And use devm_platform_get_and_ioremap_resource() to simplify code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add accessors to read/set tp->snd_cwndWe had various bugs over the years with codebreaking the assumption that tp->snd_cwnd is greaterthan zero.Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) addedin commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")can trigger, and without a repro we would have to spendconsiderable time finding the bug.Instead of complaining too late, we want to catch whereand when tp->snd_cwnd is set to an illegal value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtl818x: Prevent using not initialized queuesUsing not existing queues can panic the kernel with rtl8180/rtl8185 cards.Ignore the skb priority for those cards, they only have one tx queue. PierreAsselin (pa@panix.com) reported the kernel crash in the Gentoo forum:https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.htmlHe also confirmed that this patch fixes the issue. In summary this happened:After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a"divide error: 0000" when connecting to an AP. Control port tx now tries touse IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in2.10.Since only the rtl8187se part of the driver supports QoS, the priorityof the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185cards.rtl8180 is then unconditionally reading out the priority and finally crashes ondrivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without thispatch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never gotinitialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix tcp_mtup_probe_success vs wrong snd_cwndsyzbot got a new report [1] finally pointing to a very old bug,added in initial support for MTU probing.tcp_mtu_probe() has checks about starting an MTU probe iftcp_snd_cwnd(tp) >= 11.But nothing prevents tcp_snd_cwnd(tp) to be reduced laterand before the MTU probe succeeds.This bug would lead to potential zero-divides.Debugging added in commit 40570375356c ("tcp: add accessorsto read/set tp->snd_cwnd") has paid off :)While we are at it, address potential overflows in this code.[1]WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Modules linked in:CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ffRSP: 0018:ffffc900079e70f8 EFLAGS: 00010287RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9fRBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f6431289109Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000aRBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handlingError paths do not free previously allocated memory. Add devm_kfree() tothose failure paths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Address NULL pointer dereference after starget_to_rport()Calls to starget_to_rport() may return NULL. Add check for NULL rportbefore dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.Submitting a cs with 0 chunks, causes an oops later, found tryingto execute the wrong userspace driver.MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo[172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8[172536.665188] #PF: supervisor read access in kernel mode[172536.665189] #PF: error_code(0x0000) - not-present page[172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0[172536.665195] Oops: 0000 [#1] SMP NOPTI[172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS[172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015[172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu][172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10[172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246[172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68[172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38[172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40[172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28[172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000[172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0[172536.665287] Call Trace:[172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu][172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm][172536.665338] drm_ioctl+0x201/0x3b0 [drm][172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu][172536.665372] ? selinux_file_ioctl+0x135/0x230[172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu][172536.665403] __x64_sys_ioctl+0x83/0xb0[172536.665406] do_syscall_64+0x33/0x40[172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: dlmfs: fix error handling of user_dlm_destroy_lockWhen user_dlm_destroy_lock failed, it didn't clean up the flags it setbefore exit. For USER_LOCK_IN_TEARDOWN, if this function fails because oflock is still in used, next time when unlink invokes this function, itwill return succeed, and then unlink will remove inode and dentry if lockis not in used(file closed), but the dlm lock is still linked in dlm lockresource, then when bast come in, it will trigger a panic due touser-after-free. See the following panic call trace. To fix this,USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error shouldbe returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlinkfail.For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,USER_LOCK_BUSY is also required to be cleared. Even though spin lock isreleased in between, but USER_LOCK_IN_TEARDOWN is still set, forUSER_LOCK_BUSY, if before every place that waits on this flag,USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flowwaits on the busy flag set by user_dlm_destroy_lock(), then we cansimplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fixuser_dlm_cluster_lock() which is the only function not following this.[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink004fb0000060000b5a90b8c847b72e1, error -16 from destroy[ 989.757536] ------------[ cut here ]------------[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173![ 989.757876] invalid opcode: 0000 [#1] SMP[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntallocxen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfsocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fcfcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llcrds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umadrdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_madib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_supportpcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_siipmi_msghandler[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptppps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intelbe2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdiolibiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmidm_mirror dm_region_hash dm_log dm_mod [last unloaded:ksplice_2zhuk2jr_ib_ipoib_old][ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE4.1.12-124.57.1.el6uek.x86_64 #2[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVERX5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:ffff88017f7c8000[ 989.762848] RIP: e030:[] []__user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs][ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246[ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:0000000000000003[ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:ffff880174d48170[ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:0000000000000000[ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:ffff880174d48008[ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:ffff88021db7a000[ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)knlGS:ffff880247480000[ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033[ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:0000000000042660[ 989.765081] Stack:[ 989.765167] 00000000000---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix a data-race in unix_dgram_peer_wake_me().unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'slock held and check if its receive queue is full. Here we need touse unix_recvq_full_lockless() instead of unix_recvq_full(), otherwiseKCSAN will report a data-race.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: xfrm: unexport __init-annotated xfrm4_protocol_init()EXPORT_SYMBOL and __init is a bad combination because the .init.textsection is freed up after the initialization. Hence, modules cannotuse symbols annotated __init. The access to a freed symbol may end upwith kernel panic.modpost used to detect it, but it has been broken for a decade.Recently, I fixed modpost so it started to warn it again, then thisshowed up in linux-next builds.There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOLI chose the latter for this case because the only in-tree call-site,net/ipv4/xfrm4_policy.c is never compiled as modular.(CONFIG_XFRM is boolean)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug_on in ext4_writepageswe got issue as follows:EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls------------[ cut here ]------------kernel BUG at fs/ext4/inode.c:2708!invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155RIP: 0010:ext4_writepages+0x1977/0x1c10RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90It may happen as follows:1. write inline_data inodevfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA2. fallocatedo_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA3. writepages__ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))The root cause of this issue is we destory inline data until callext4_writepages under delay allocation mode. But there maybe alreadyconvert from inline to extent. To solve this issue, we callfilemap_flush first..
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free in ext4_rename_dir_prepareWe got issue as follows:EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continueext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae==================================================================BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220Read of size 4 at addr ffff88810beee6ae by task rep/1895CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9RIP: 0033:0x7f45a6fc41c9RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000The buggy address belongs to the page:page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beeeflags: 0x200000000000000()raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff>ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff==================================================================Disabling lock debugging due to kernel taintext4_rename_dir_prepare: [2] parent_de->inode=3537895424ext4_rename_dir_prepare: [3] dir=0xffff888124170140ext4_rename_dir_prepare: [4] ino=2ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872Reason is first directory entry which 'rec_len' is 34478, then will get illegalparent entry. Now, we do not check directory entry after read directory blockin 'ext4_get_first_dir_block'.To solve this issue, check directory entry in 'ext4_get_first_dir_block'.[ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: altera: Fix refcount leak in altera_tse_mdio_createEvery iteration of for_each_child_of_node() decrementsthe reference count of the previous node.When break from a for_each_child_of_node() loop,we need to explicitly call of_node_put() on the child node whennot need anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_registerof_get_child_by_name() returns a node pointer with refcountincremented, we should use of_node_put() on it when done.mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().We don't need the device node after it.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handlekobject_init_and_add() takes reference even when it fails.According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.Fix this issue by calling kobject_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix deadlock in __device_attachIn __device_attach function, The lock holding logic is as follows:...__device_attachdevice_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev)As shown above, when it is allowed to do async probes, because ofout of memory or work limit, async work is not allowed, to dosync execute instead. it will lead to A-A deadlock because of__device_attach_async_helper getting lock dev.To fix the deadlock, move the async_schedule_dev outside device_lock,as we can see, in async_schedule_node_domain, the parameter ofqueue_work_node is system_unbound_wq, so it can accept concurrentoperations. which will also not change the code logic, and willnot lead to deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_rtx_synack() can be called from process contextLaurent reported the enclosed report [1]This bug triggers with following coditions:0) Kernel built with CONFIG_DEBUG_PREEMPT=y1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one.2) A socket operation on this socket goes through lock_sock() release_sock() dance.3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog.4) At release_sock() time, the socket backlog is processed while in process context.5) A SYNACK packet is cooked in response of the SYN retransmit.6) -> tcp_rtx_synack() is called in process context.Before blamed commit, tcp_rtx_synack() was always called from BH handler,from a timer handler.Fix this by using TCP_INC_STATS() & NET_INC_STATS()which do not assume caller is in non preemptible context.[1]BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180caller is tcp_rtx_synack.part.0+0x36/0xc0CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: rockchip: Fix refcount leak in rockchip_grf_initof_find_matching_node_and_match returns a node pointer with refcountincremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver: base: fix UAF when driver_attach failedWhen driver_attach(drv); failed, the driver_private will be freed.But it has been added to the bus, which caused a UAF.To fix it, we need to delete it from the bus when failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: ubi_create_volume: Fix use-after-free when volume creation failedThere is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'serror handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tblout_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAFFix it by removing redundant 'eba_tbl' releasing.Fetch a reproducer in [Link].
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: usbip: fix a refcount leak in stub_probe()usb_get_dev() is called in stub_device_alloc(). When stub_probe() failsafter that, usb_put_dev() needs to be called to release the reference.Fix this by moving usb_put_dev() to sdev_free error path handling.Find this by code review.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macsec: fix UAF bug for real_devCreate a new macsec device but not get reference to real_dev. That cannot ensure that real_dev is freed after macsec. That will trigger theUAF bug for real_dev as following:==================================================================BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), wecan add dev_hold_track() in macsec_dev_init() and dev_put_track() inmacsec_free_netdev() to fix the problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:um: Fix out-of-bounds read in LDT setupsyscall_stub_data() expects the data_count parameter to be the number oflongs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qmp: fix reset-controller leak on probe errorsMake sure to release the lane reset controller in case of a late probeerror (e.g. probe deferral).Note that due to the reset controller being defined in devicetree in"lane" child nodes, devm_reset_control_get_exclusive() cannot be useddirectly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qmp: fix struct clk leak on probe errorsMake sure to release the pipe clock reference in case of a late probeerror (e.g. probe deferral).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Fix potential integer multiplication overflow errorsWhen multiplying of different types, an overflow is possible even whenstoring the result in a larger type. This is because the conversion isdone after the multiplication. So arithmetic overflow and thus inincorrect value is possible.Correct an instance of this in the inter packet delay calculation. Fix byensuring one of the operands is u64 which will promote the other to u64 aswell ensuring no overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix plock invalid readThis patch fixes an invalid read showed by KASAN. A unlock will allocate a"struct plock_op" and a followed send_op() will append it to a globalsend_list data structure. In some cases a followed dev_read() moves itto recv_list and dev_write() will cast it to "struct plock_xop" and accessfields which are only available in those structures. At this point aninvalid read happens by accessing those fields.To fix this issue the "callback" field is moved to "struct plock_op" toindicate that a cast to "plock_xop" is allowed and does the additional"plock_xop" handling if set.Example of the KASAN output which showed the invalid read:[ 2064.296453] ==================================================================[ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm][ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484[ 2064.308168][ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9[ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011[ 2064.311618] Call Trace:[ 2064.312218] dump_stack_lvl+0x56/0x7b[ 2064.313150] print_address_description.constprop.8+0x21/0x150[ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm][ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm][ 2064.316595] kasan_report.cold.14+0x7f/0x11b[ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm][ 2064.318687] dev_write+0x52b/0x5a0 [dlm][ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm][ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10[ 2064.321926] vfs_write+0x17e/0x930[ 2064.322769] ? __fget_light+0x1aa/0x220[ 2064.323753] ksys_write+0xf1/0x1c0[ 2064.324548] ? __ia32_sys_read+0xb0/0xb0[ 2064.325464] do_syscall_64+0x3a/0x80[ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 2064.327606] RIP: 0033:0x7f807e4ba96f[ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48[ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001[ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f[ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010[ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001[ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80[ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001[ 2064.342857][ 2064.343226] Allocated by task 12438:[ 2064.344057] kasan_save_stack+0x1c/0x40[ 2064.345079] __kasan_kmalloc+0x84/0xa0[ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220[ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm][ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0[ 2064.351070] fcntl_setlk+0x281/0xbc0[ 2064.352879] do_fcntl+0x5e4/0xfe0[ 2064.354657] __x64_sys_fcntl+0x11f/0x170[ 2064.356550] do_syscall_64+0x3a/0x80[ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 2064.360745][ 2064.361511] Last potentially related work creation:[ 2064.363957] kasan_save_stack+0x1c/0x40[ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0[ 2064.368100] call_rcu+0x11b/0xf70[ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm][ 2064.372404] receive_from_sock+0x290/0x770 [dlm][ 2064.374607] process_recv_sockets+0x32/0x40 [dlm][ 2064.377290] process_one_work+0x9a8/0x16e0[ 2064.379357] worker_thread+0x87/0xbf0[ 2064.381188] kthread+0x3ac/0x490[ 2064.383460] ret_from_fork+0x22/0x30[ 2064.385588][ 2064.386518] Second to last potentially related work creation:[ 2064.389219] kasan_save_stack+0x1c/0x40[ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0[ 2064.393303] call_rcu+0x11b/0xf70[ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm][ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug_on in __es_tree_searchHulk Robot reported a BUG_ON:==================================================================kernel BUG at fs/ext4/extents_status.c:199![...]RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline]RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217[...]Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261[...]==================================================================Above issue may happen as follows:-------------------------------------ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk)The error ext4 extents is as follows:0af3 0300 0400 0000 00000000 extent_header00000000 0100 0000 12000000 extent100000000 0100 0000 18000000 extent202000000 0400 0000 14000000 extent3In the ext4_valid_extent_entries function,if prev is 0, no error is returned even if lblock<=prev.This was intended to skip the check on the first extent, butin the error image above, prev=0+1-1=0 when checking the second extent,so even though lblock<=prev, the function does not return an error.As a result, bug_ON occurs in __es_tree_search and the system panics.To solve this problem, we only need to check that:1. The lblock of the first extent is not less than 0.2. The lblock of the next extent is not less than the next block of the previous extent.The same applies to extent_idx.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bfq: Make sure bfqg for which we are queueing requests is onlineBios queued into BFQ IO scheduler can be associated with a cgroup thatwas already offlined. This may then cause insertion of this bfq_groupinto a service tree. But this bfq_group will get freed as soon as lastbio associated with it is completed leading to use after free issues forservice tree users. Fix the problem by making sure we always operate ononline bfq_group. If the bfq_group associated with the bio is notonline, we pick the first online parent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix race condition between ext4_write and ext4_convert_inline_dataHulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ==================================================================Above issue may happen as follows: cpu1 cpu2__________________________|__________________________do_pwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ONThe lock held by ext4_convert_inline_data is xattr_sem, but the lockheld by generic_perform_write is i_rwsem. Therefore, the two locks canbe concurrent.To solve above issue, we add inode_lock() for ext4_convert_inline_data().At the same time, move ext4_convert_inline_data() in front ofext4_punch_hole(), remove similar handling from ext4_punch_hole().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix use-after-free in chanctx codeIn ieee80211_vif_use_reserved_context(), when we have anold context and the new context's replace_state is set toIEEE80211_CHANCTX_REPLACE_NONE, we free the old contextin ieee80211_vif_use_reserved_reassign(). Therefore, wecannot check the old_ctx anymore, so we should set it toNULL after this point.However, since the new_ctx replace state is clearly notIEEE80211_CHANCTX_REPLACES_OTHER, we're not going to doanything else in this function and can just return toavoid accessing the freed old_ctx.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate races around sk->sk_bound_dev_ifUDP sendmsg() is lockless, and reads sk->sk_bound_dev_if whilethis field can be changed by another thread.Adds minimal annotations to avoid KCSAN splats for UDP.Following patches will add more annotations to potential lockless readers.BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsgwrite to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0x00000000 -> 0xffffff9bReported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011I chose to not add Fixes: tag because race has minor consequencesand stable teams busy enough.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setupof_parse_phandle() returns a node pointer with refcount incremented, we shoulduse of_node_put() on it when not need anymore. Add missing of_node_put() toavoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Prevent panic when SDMA is disabledIf the hfi1 module is loaded with HFI1_CAP_SDMA off, a call tohfi1_write_iter() will dereference a NULL pointer and panic. A typicalstack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64The fix is to test for SDMA in hfi1_write_iter() and fail the I/O withEINVAL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/xics: fix refcount leak in icp_opal_init()The of_find_compatible_node() function returns a node pointer withrefcount incremented, use of_node_put() on it when done.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: Prevent use of lock before it is initializedIf there is a failure during probe of hfi1 before the sdma_map_lock isinitialized, the call to hfi1_free_devdata() will attempt to use a lockthat has not been initialized. If the locking correctness validator is onthen an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0The use of sdma_map_lock in sdma_clean() is for freeing the sdma_mapmemory, and sdma_map is not allocated/initialized until aftersdma_map_lock has been initialized. This code only needs to be run ifsdma_map is not NULL, and so checking for that condition will avoid tryingto use the lock before it is initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()The sysfs sriov_numvfs_store() path acquires the device lock before theconfig space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0Previously, pci_dev_lock() acquired the config space access lock before thedevice lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lockAny path that uses pci_dev_lock(), e.g., pci_reset_function(), maydeadlock with sriov_numvfs_store() if the operations occur in the sequence(1) (2) (3) (4).Avoid the deadlock by reversing the order in pci_dev_lock() so it acquiresthe device lock before the config space access lock, the same as thesriov_numvfs_store() path.[bhelgaas: combined and adapted commit log from Jay Zhou's independentsubsequent posting:https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/xive: Fix refcount leak in xive_spapr_initof_find_compatible_node() returns a node pointer with refcountincremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: fix deadlock caused by calling printk() under tty_port->lockpty_write() invokes kmalloc() which may invoke a normal printk() to printfailure message. This can cause a deadlock in the scenario reported bysyz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner);As commit dbdda842fe96 ("printk: Add console owner and waiter logic toload balance console writes") said, such deadlock can be prevented byusing printk_deferred() in kmalloc() (which is invoked in the sectionguarded by the port->lock). But there are too many printk() on thekmalloc() path, and kmalloc() can be called from anywhere, so changingprintk() to printk_deferred() is too complicated and inelegant.Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), sothat printk() will not be called, and this deadlock problem can beavoided.Syzbot reported the following lockdep error:======================================================WARNING: possible circular locking dependency detected5.4.143-00237-g08ccc19a-dirty #10 Not tainted------------------------------------------------------syz-executor.4/29420 is trying to acquire lock:ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023but task is already holding lock:ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...]-> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241-> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers/base/node.c: fix compaction sysfs file leakCompaction sysfs file is created via compaction_register_node inregister_node. But we forgot to remove it in unregister_node. Thuscompaction sysfs file is leaked. Using compaction_unregister_node to fixthis issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:list: fix a data-race around ep->rdllistep_poll() first calls ep_events_available() with no lock held and checksif ep->rdllist is empty by list_empty_careful(), which readsrdllist->prev. Thus all accesses to it need some protection to avoidstore/load-tearing.Note INIT_LIST_HEAD_RCU() already has the annotation for both prevand next.Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socketfds.") added the first lockless ep_events_available(), and commitc5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()")made some ep_events_available() calls lockless and added single call undera lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lockfor zero timeout") made the last ep_events_available() lockless.BUG: KCSAN: data-race in do_epoll_wait / do_epoll_waitwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0xffff88810480c7d0 -> 0xffff888103c15098Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:module: fix [e_shstrndx].sh_size=0 OOB accessIt is trivial to craft a module to trigger OOB access in this line: if (info->secstrings[strhdr->sh_size - 1] != '\0') {BUG: unable to handle page fault for address: ffffc90000aa0fffPGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014RIP: 0010:load_module+0x19b/0x2391[rebased patch onto modules-next]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources()It will cause null-ptr-deref when using 'res', if platform_get_resource()returns NULL, so move using 'res' after devm_ioremap_resource() thatwill check it to avoid null-ptr-deref.And use devm_platform_get_and_ioremap_resource() to simplify code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: rk3399_dmc: Disable edev on remove()Otherwise we hit an unablanced enable-count when unbinding the DFIdevice:[ 1279.659119] ------------[ cut here ]------------[ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c...[ 1279.659352] Hardware name: Google Kevin (DT)[ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--)[ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c[ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28...[ 1279.659571] Call trace:[ 1279.659582] devfreq_event_remove_edev+0x84/0x8c[ 1279.659590] devm_devfreq_event_release+0x1c/0x28[ 1279.659602] release_nodes+0x1cc/0x244[ 1279.659611] devres_release_all+0x44/0x60[ 1279.659621] device_release_driver_internal+0x11c/0x1ac[ 1279.659629] device_driver_detach+0x20/0x2c[ 1279.659641] unbind_store+0x7c/0xb0[ 1279.659650] drv_attr_store+0x2c/0x40[ 1279.659663] sysfs_kf_write+0x44/0x58[ 1279.659672] kernfs_fop_write_iter+0xf4/0x190[ 1279.659684] vfs_write+0x2b0/0x2e4[ 1279.659693] ksys_write+0x80/0xec[ 1279.659701] __arm64_sys_write+0x24/0x30[ 1279.659714] el0_svc_common+0xf0/0x1d8[ 1279.659724] do_el0_svc_compat+0x28/0x3c[ 1279.659738] el0_svc_compat+0x10/0x1c[ 1279.659746] el0_sync_compat_handler+0xa8/0xcc[ 1279.659758] el0_sync_compat+0x188/0x1c0[ 1279.659768] ---[ end trace cec200e5094155b4 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_boneeds to be put when msm_gem_get_and_pin_iova fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: micrel: Allow probing without .driver_dataCurrently, if the .probe element is present in the phy_driver structureand the .driver_data is not, a NULL pointer dereference happens.Allow passing .probe without .driver_data by inserting NULL checksfor priv->type.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeoutConnecting the same socket twice consecutively in sco_sock_connect()could lead to a race condition where two sco_conn objects are createdbut only one is associated with the socket. If the socket is closedbefore the SCO connection is established, the timer associated with thedangling sco_conn object won't be canceled. As the sock object is beingfreed, the use-after-free problem happens when the timer callbackfunction sco_sock_timeout() accesses the socket. Here's the call trace:dump_stack+0x107/0x163? refcount_inc+0x1c/print_address_description.constprop.0+0x1c/0x47e? refcount_inc+0x1c/0x7bkasan_report+0x13a/0x173? refcount_inc+0x1c/0x7bcheck_memory_region+0x132/0x139refcount_inc+0x1c/0x7bsco_sock_timeout+0xb2/0x1baprocess_one_work+0x739/0xbd1? cancel_delayed_work+0x13f/0x13f? __raw_spin_lock_init+0xf0/0xf0? to_kthread+0x59/0x85worker_thread+0x593/0x70ekthread+0x346/0x35a? drain_workqueue+0x31a/0x31a? kthread_bind+0x4b/0x4bret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_initSyzbot reported that -1 is used as array index. The problem was inmissing validation check.hdw->unit_number is initialized with -1 and then if init table walk failsthis value remains unchanged. Since code blindly uses this member forarray indexing adding sanity check is the easiest fix for that.hdw->workpoll initialization moved upper to prevent warning in__flush_work.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detectedThere is a possibility for mdp5_get_global_state to return-EDEADLK when acquiring the modeset lock, but currently global_state inmdp5_mixer_release doesn't check for if an error is returned.To avoid a NULL dereference error, let's have mdp5_mixer_releasecheck if an error is returned and propagate that error.Patchwork: https://patchwork.freedesktop.org/patch/485181/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resumeBUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16cPatchwork: https://patchwork.freedesktop.org/patch/483255/[DB: fixed Fixes tag]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detectedmdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiringthe modeset lock, but currently mdp5_pipe_release doesn't check for ifan error is returned. Because of this, there is a possibility ofmdp5_pipe_release hitting a NULL dereference error.To avoid this, let's have mdp5_pipe_release check ifmdp5_get_global_state returns an error and propogate that error.Changes since v1:- Separated declaration and initialization of *new_state to avoid compiler warning- Fixed some spelling mistakes in commit messageChanges since v2:- Return 0 in case where hwpipe is NULL as this is considered normal behavior- Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_releasePatchwork: https://patchwork.freedesktop.org/patch/485179/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()It will cause null-ptr-deref in resource_size(), if platform_get_resource()returns NULL, move calling resource_size() after devm_ioremap_resource() thatwill check 'res' to avoid null-ptr-deref.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tagsIn nvme_alloc_admin_tags, the admin_q can be set to an error (typically-ENOMEM) if the blk_mq_init_queue call fails to set up the queue, whichis checked immediately after the call. However, when we return the errormessage up the stack, to nvme_reset_work the error takes us tonvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]).Here, we only check that the admin_q is non-NULL, rather than notan error or NULL, and begin quiescing a queue that never existed, leadingto bad / NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/hdmi: check return value after calling platform_get_resource_byname()It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,we need check the return value.Patchwork: https://patchwork.freedesktop.org/patch/482992/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: remove two BUG() from skb_checksum_help()I have a syzbot report that managed to get a crash in skb_checksum_help()If syzbot can trigger these BUG(), it makes sense to replacethem with more friendly WARN_ON_ONCE() since skb_checksum_help()can instead return an error code.Note that syzbot will still crash there, until real bug is fixed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyixThe "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need toensure that it is within the bitmap.drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept()error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Inhibit aborts if external loopback plug is insertedAfter running a short external loopback test, when the external loopback isremoved and a normal cable inserted that is directly connected to a targetdevice, the system oops in the llpfc_set_rrq_active() routine.When the loopback was inserted an FLOGI was transmit. As we're looped back,we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the samewppn thus understand it's a loopback. However, as the ABTS sends addressinformation the port is not set to (fffffe), the ABTS is dropped on thewire. A short 1 frame loopback test is run and completes before the ABTStimes out. The looback is unplugged and the new cable plugged in, and thean FLOGI to the new device occurs and completes. Due to a mixup in refcounting the completion of the new FLOGI releases the fabric ndlp. Then theoriginal ABTS completes and references the released ndlp generating theoops.Correct by no-op'ing the ABTS when in loopback mode (it will be droppedanyway). Added a flag to track the mode to recognize when it should beno-op'd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: NULL out the dev->rfkill to prevent UAFCommit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")assumes the device_is_registered() in function nfc_dev_up() will helpto check when the rfkill is unregistered. However, this check onlytake effect when device_del(&dev->dev) is done in nfc_unregister_device().Hence, the rfkill object is still possible be dereferenced.The crash trace in latest kernel (5.18-rc2):[ 68.760105] ==================================================================[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313[ 68.760756][ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 68.760756] Call Trace:[ 68.760756] [ 68.760756] dump_stack_lvl+0x57/0x7d[ 68.760756] print_report.cold+0x5e/0x5db[ 68.760756] ? __lock_acquire+0x3ec1/0x6750[ 68.760756] kasan_report+0xbe/0x1c0[ 68.760756] ? __lock_acquire+0x3ec1/0x6750[ 68.760756] __lock_acquire+0x3ec1/0x6750[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 68.760756] ? register_lock_class+0x18d0/0x18d0[ 68.760756] lock_acquire+0x1ac/0x4f0[ 68.760756] ? rfkill_blocked+0xe/0x60[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0[ 68.760756] ? nla_get_range_signed+0x540/0x540[ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50[ 68.760756] _raw_spin_lock_irqsave+0x39/0x50[ 68.760756] ? rfkill_blocked+0xe/0x60[ 68.760756] rfkill_blocked+0xe/0x60[ 68.760756] nfc_dev_up+0x84/0x260[ 68.760756] nfc_genl_dev_up+0x90/0xe0[ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0[ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230[ 68.760756] ? security_capable+0x51/0x90[ 68.760756] genl_rcv_msg+0x280/0x500[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0[ 68.760756] ? lock_acquire+0x1ac/0x4f0[ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410[ 68.760756] netlink_rcv_skb+0x11b/0x340[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0[ 68.760756] ? netlink_ack+0x9c0/0x9c0[ 68.760756] ? netlink_deliver_tap+0x136/0xb00[ 68.760756] genl_rcv+0x1f/0x30[ 68.760756] netlink_unicast+0x430/0x710[ 68.760756] ? memset+0x20/0x40[ 68.760756] ? netlink_attachskb+0x740/0x740[ 68.760756] ? __build_skb_around+0x1f4/0x2a0[ 68.760756] netlink_sendmsg+0x75d/0xc00[ 68.760756] ? netlink_unicast+0x710/0x710[ 68.760756] ? netlink_unicast+0x710/0x710[ 68.760756] sock_sendmsg+0xdf/0x110[ 68.760756] __sys_sendto+0x19e/0x270[ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0[ 68.760756] ? fd_install+0x178/0x4c0[ 68.760756] ? fd_install+0x195/0x4c0[ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0[ 68.760756] __x64_sys_sendto+0xd8/0x1b0[ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130[ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50[ 68.760756] do_syscall_64+0x3b/0x90[ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 68.760756] RIP: 0033:0x7f67fb50e6b3...[ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c[ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3[ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003[ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c[ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e[ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003[ 68.760756] [ 68.760756][ 68.760756] Allocated by task 279:[ 68.760756] kasan_save_stack+0x1e/0x40[---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: Use kobject release() method to free dbs_dataThe struct dbs_data embeds a struct gov_attr_set andthe struct gov_attr_set embeds a kobject. Since every kobject must havea release() method and we can't use kfree() to free it directly,so introduce cpufreq_dbs_data_release() to release the dbs_data viathe kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4[ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: always check VF VSI pointer valuesThe ice_get_vf_vsi function can return NULL in some cases, such as ifhandling messages during a reset where the VSI is being removed andrecreated.Several places throughout the driver do not bother to check whether thisVSI pointer is valid. Static analysis tools maybe report issues becausethey detect paths where a potentially NULL pointer could be dereferenced.Fix this by checking the return value of ice_get_vf_vsi everywhere.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath10k: skip ath10k_halt during suspend for driver state RESTARTINGDouble free crash is observed when FW recovery(caused by wmitimeout/crash) is followed by immediate suspend event. The FW recoveryis triggered by ath10k_core_restart() which calls driver clean up viaath10k_halt(). When the suspend event occurs between the FW recovery,the restart worker thread is put into frozen state until suspend completes.The suspend event triggers ath10k_stop() which again triggers ath10k_halt()The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to becalled twice(Note: ath10k_htt_rx_alloc was not called by restart workerthread because of its frozen state), causing the crash.To fix this, during the suspend flow, skip call to ath10k_halt() inath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING.Also, for driver state ATH10K_STATE_RESTARTING, callath10k_wait_for_suspend() in ath10k_stop(). This is because call toath10k_wait_for_suspend() is skipped later in[ath10k_halt() > ath10k_core_stop()] for the driver stateATH10K_STATE_RESTARTING.The frozen restart worker thread will be cancelled during resume when thedevice comes out of suspend.Below is the crash stack for reference:[ 428.469167] ------------[ cut here ]------------[ 428.469180] kernel BUG at mm/slub.c:4150![ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 428.469219] Workqueue: events_unbound async_run_entry_fn[ 428.469230] RIP: 0010:kfree+0x319/0x31b[ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246[ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000[ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000[ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000[ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 428.469285] Call Trace:[ 428.469295] ? dma_free_attrs+0x5f/0x7d[ 428.469320] ath10k_core_stop+0x5b/0x6f[ 428.469336] ath10k_halt+0x126/0x177[ 428.469352] ath10k_stop+0x41/0x7e[ 428.469387] drv_stop+0x88/0x10e[ 428.469410] __ieee80211_suspend+0x297/0x411[ 428.469441] rdev_suspend+0x6e/0xd0[ 428.469462] wiphy_suspend+0xb1/0x105[ 428.469483] ? name_show+0x2d/0x2d[ 428.469490] dpm_run_callback+0x8c/0x126[ 428.469511] ? name_show+0x2d/0x2d[ 428.469517] __device_suspend+0x2e7/0x41b[ 428.469523] async_suspend+0x1f/0x93[ 428.469529] async_run_entry_fn+0x3d/0xd1[ 428.469535] process_one_work+0x1b1/0x329[ 428.469541] worker_thread+0x213/0x372[ 428.469547] kthread+0x150/0x15f[ 428.469552] ? pr_cont_work+0x58/0x58[ 428.469558] ? kthread_blkcg+0x31/0x31Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp()If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of areceived frame, the frame is dropped and resources are leaked.Fix by returning resources when discarding an unhandled frame type. Updatelpfc_fc_frame_check() handling of NOP basic link service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: Fix the error handling in cx23885_initdev()When the driver fails to call the dma_set_mask(), the driver will getthe following splat:[ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240[ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590[ 55.856822] Call Trace:[ 55.860327] __process_removed_driver+0x3c/0x240[ 55.861347] bus_for_each_dev+0x102/0x160[ 55.861681] i2c_del_driver+0x2f/0x50This is because the driver has initialized the i2c related resourcesin cx23885_dev_setup() but not released them in error handling, fix thisbug by modifying the error path that jumps after failing to call thedma_set_mask().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx25821: Fix the warning when removing the moduleWhen removing the module, we will get the following warning:[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0[ 14.759589] Call Trace:[ 14.759792] [ 14.759975] unregister_irq_proc+0x14c/0x170[ 14.760340] irq_free_descs+0x94/0xe0[ 14.760640] mp_unmap_irq+0xb6/0x100[ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40[ 14.761334] acpi_pci_irq_disable+0x1d3/0x320[ 14.761688] pci_disable_device+0x1ad/0x380[ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60[ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821][ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821][ 14.763242] pci_device_remove+0x92/0x240Fix this by freeing the irq before call pci_disable_device().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/bitmap: don't set sb values if can't pass sanity checkIf bitmap area contains invalid data, kernel will crash then mdadmtriggers "Segmentation fault".This is cluster-md speical bug. In non-clustered env, mdadm willhandle broken metadata case. In clustered array, only kernel spacehandles bitmap slot info. But even this bug only happened in clusteredenv, current sanity check is wrong, the code should be changed.How to trigger: (faulty injection)dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdadd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdbmdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdbmdadm -Ssecho aaa > magic.txt == below modifying slot 2 bitmap data ==dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magicdd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksizemdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" ==Reason of kernel crash:In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn'tblock chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T()trigger "divide error".Crash log:kernel: md: md0 stopped.kernel: md/raid1:md0: not clean -- starting background reconstructionkernel: md/raid1:md0: active with 2 out of 2 mirrorskernel: dlm: ... ...kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1kernel: md0: invalid bitmap file superblock: bad magickernel: md_bitmap_copy_from_slot can't get bitmap from slot 2kernel: md-cluster: Could not gather bitmaps from slot 2kernel: divide error: 0000 [#1] SMP NOPTIkernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-defaultkernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246kernel: ... ...kernel: Call Trace:kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0]kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a]kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0]kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a]kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a]kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a]kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a]kernel: ? blkdev_ioctl+0xb1/0x2b0kernel: block_ioctl+0x3b/0x40kernel: __x64_sys_ioctl+0x7f/0xb0kernel: do_syscall_64+0x59/0x80kernel: ? exit_to_user_mode_prepare+0x1ab/0x230kernel: ? syscall_exit_to_user_mode+0x18/0x40kernel: ? do_syscall_64+0x69/0x80kernel: entry_SYSCALL_64_after_hwframe+0x44/0xaekernel: RIP: 0033:0x7f4a15fa722bkernel: ... ...kernel: ---[ end trace 8afa7612f559c868 ]---kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix double free in si_parse_power_table()In function si_parse_power_table(), array adev->pm.dpm.ps and its memberis allocated. If the allocation of each member fails, the array itselfis freed and returned with an error code. However, the array is laterfreed again in si_dpm_fini() function which is called when the functionreturns an error.This leads to potential double free of the array adev->pm.dpm.ps, aswell as leak of its array members, since the members are not freed inthe allocation function and the array is not nulled when freed.In addition adev->pm.dpm.num_ps, which keeps track of the allocatedarray member, is not updated until the member allocation issuccessfully finished, this could also lead to either use after free,or uninitialized variable access in si_dpm_fini().Fix this by postponing the free of the array until si_dpm_fini() andincrement adev->pm.dpm.num_ps everytime the array member is allocated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modesdrm_cvt_mode may return NULL and we should check it.This bug is found by syzkaller:FAULT_INJECTION stacktrace:[ 168.567394] FAULT_INJECTION: forcing a failure.name failslab, interval 1, probability 0, space 0, times 1[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015[ 168.567408] Call trace:[ 168.567414] dump_backtrace+0x0/0x310[ 168.567418] show_stack+0x28/0x38[ 168.567423] dump_stack+0xec/0x15c[ 168.567427] should_fail+0x3ac/0x3d0[ 168.567437] __should_failslab+0xb8/0x120[ 168.567441] should_failslab+0x28/0xc0[ 168.567445] kmem_cache_alloc_trace+0x50/0x640[ 168.567454] drm_mode_create+0x40/0x90[ 168.567458] drm_cvt_mode+0x48/0xc78[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu][ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80[ 168.567492] drm_mode_getconnector+0x2e0/0xa70[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8[ 168.567514] drm_ioctl+0x558/0x6d0[ 168.567522] do_vfs_ioctl+0x160/0xf30[ 168.567525] ksys_ioctl+0x98/0xd8[ 168.567530] __arm64_sys_ioctl+0x50/0xc8[ 168.567536] el0_svc_common+0xc8/0x320[ 168.567540] el0_svc_handler+0xf8/0x160[ 168.567544] el0_svc+0x10/0x218KASAN stacktrace:[ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu][ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425[ 168.567566][ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015[ 168.567575] Call trace:[ 168.567578] dump_backtrace+0x0/0x310[ 168.567582] show_stack+0x28/0x38[ 168.567586] dump_stack+0xec/0x15c[ 168.567591] kasan_report+0x244/0x2f0[ 168.567594] __asan_load4+0x58/0xb0[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu][ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80[ 168.567617] drm_mode_getconnector+0x2e0/0xa70[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8[ 168.567624] drm_ioctl+0x558/0x6d0[ 168.567628] do_vfs_ioctl+0x160/0xf30[ 168.567632] ksys_ioctl+0x98/0xd8[ 168.567636] __arm64_sys_ioctl+0x50/0xc8[ 168.567641] el0_svc_common+0xc8/0x320[ 168.567645] el0_svc_handler+0xf8/0x160[ 168.567649] el0_svc+0x10/0x218
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGIIf lpfc_issue_els_flogi() fails and returns non-zero status, the nodereference count is decremented to trigger the release of the nodeliststructure. However, if there is a prior registration or dev-loss-evt workpending, the node may be released prematurely. When dev-loss-evtcompletes, the released node is referenced causing a use-after-free nullpointer dereference.Similarly, when processing non-zero ELS PLOGI completion status inlpfc_cmpl_els_plogi(), the ndlp flags are checked for a transportregistration before triggering node removal. If dev-loss-evt work ispending, the node may be released prematurely and a subsequent call tolpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.Add test for pending dev-loss before decrementing the node reference countfor FLOGI, PLOGI, PRLI, and ADISC handling.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix call trace observed during I/O with CMF enabledThe following was seen with CMF enabled:BUG: using smp_processor_id() in preemptiblecode: systemd-udevd/31711kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc]kernel: CPU: 12 PID: 31711 Comm: systemd-udevdkernel: Call Trace:kernel: kernel: dump_stack_lvl+0x44/0x57kernel: check_preemption_disabled+0xbf/0xe0kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc]kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc]this_cpu_ptr() calls smp_processor_id() in a preemptible context.Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: jack: Access input_dev under mutexIt is possible when using ASoC that input_dev is unregistered whilecalling snd_jack_report, which causes NULL pointer dereference.In order to prevent this serialize access to input_dev using mutex lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hardlockup call trace hangs the system.Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40Kernel panic - not syncing: Hard LOCKUPThe same CPU tries to claim the phba->port_list_lock twice.Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() andlpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no needto take the phba->port_list_lock within lpfc_dmp_dbg().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipw2x00: Fix potential NULL dereference in libipw_xmit()crypt and crypt->ops could be null, so we need to checking nullbefore dereference
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_qca: Use del_timer_sync() before freeingWhile looking at a crash report on a timer list being corrupted, whichusually happens when a timer is freed while still active. This iscommonly triggered by code calling del_timer() instead ofdel_timer_sync() just before freeing.One possible culprit is the hci_qca driver, which does exactly that.Eric mentioned that wake_retrans_timer could be rearmed via the workqueue, so also move the destruction of the work queue beforedel_timer_sync().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: re-fetch conntrack after insertionIn case the conntrack is clashing, insertion can free skb->_nfct andset skb->_nfct to the already-confirmed entry.This wasn't found before because the conntrack entry and the extensionspace used to free'd after an rcu grace period, plus the race needsevents enabled to trigger.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - fix memory leak in RSAWhen an RSA key represented in form 2 (as defined in PKCS #1 V2.1) isused, some components of the private key persist even after the TFM isreleased.Replace the explicit calls to free the buffers in qat_rsa_exit_tfm()with a call to qat_rsa_clear_ctx() which frees all buffers referenced inthe TFM context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: Fix buffer overflow in be_get_module_eeprombe_cmd_read_port_transceiver_data assumes that it is given a buffer thatis at least PAGE_DATA_LEN long, or twice that if the module supports SFF8472. However, this is not always the case.Fix this by passing the desired offset and length tobe_cmd_read_port_transceiver_data so that we only copy the bytes once.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbe: Add locking to prevent panic when setting sriov_numvfs to zeroIt is possible to disable VFs while the PF driver is processing requestsfrom the VF driver. This can result in a panic.BUG: unable to handle kernel paging request at 000000000000106cPGD 0 P4D 0Oops: 0000 [#1] SMP NOPTICPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- -Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe]Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0aRSP: 0018:ffffb337869f8df8 EFLAGS: 00010002RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002bRDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? ttwu_do_wakeup+0x19/0x140 ? try_to_wake_up+0x1cd/0x550 ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf] ixgbe_msix_other+0x17e/0x310 [ixgbe] __handle_irq_event_percpu+0x40/0x180 handle_irq_event_percpu+0x30/0x80 handle_irq_event+0x36/0x53 handle_edge_irq+0x82/0x190 handle_irq+0x1c/0x30 do_IRQ+0x49/0xd0 common_interrupt+0xf/0xfThis can be eventually be reproduced with the following script:while :do echo 63 > /sys/class/net//device/sriov_numvfs sleep 1 echo 0 > /sys/class/net//device/sriov_numvfs sleep 1doneAdd lock when disabling SR-IOV to prevent process VF mailbox communication.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_qrv.While reading sysctl_igmp_qrv, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix dma queue left shift overflow issueWhen queue number is > 4, left shift overflows due to 32 bitsinteger variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1.If CONFIG_UBSAN is enabled, kernel dumps below warning:[ 10.363842] ==================================================================[ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12[ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int'[ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg[ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021[ 10.363958] Call Trace:[ 10.363960] [ 10.363963] dump_stack_lvl+0x4a/0x5f[ 10.363971] dump_stack+0x10/0x12[ 10.363974] ubsan_epilogue+0x9/0x45[ 10.363976] __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e[ 10.363979] ? wake_up_klogd+0x4a/0x50[ 10.363983] ? vprintk_emit+0x8f/0x240[ 10.363986] dwmac4_map_mtl_dma.cold+0x42/0x91 [stmmac][ 10.364001] stmmac_mtl_configuration+0x1ce/0x7a0 [stmmac][ 10.364009] ? dwmac410_dma_init_channel+0x70/0x70 [stmmac][ 10.364020] stmmac_hw_setup.cold+0xf/0xb14 [stmmac][ 10.364030] ? page_pool_alloc_pages+0x4d/0x70[ 10.364034] ? stmmac_clear_tx_descriptors+0x6e/0xe0 [stmmac][ 10.364042] stmmac_open+0x39e/0x920 [stmmac][ 10.364050] __dev_open+0xf0/0x1a0[ 10.364054] __dev_change_flags+0x188/0x1f0[ 10.364057] dev_change_flags+0x26/0x60[ 10.364059] do_setlink+0x908/0xc40[ 10.364062] ? do_setlink+0xb10/0xc40[ 10.364064] ? __nla_validate_parse+0x4c/0x1a0[ 10.364068] __rtnl_newlink+0x597/0xa10[ 10.364072] ? __nla_reserve+0x41/0x50[ 10.364074] ? __kmalloc_node_track_caller+0x1d0/0x4d0[ 10.364079] ? pskb_expand_head+0x75/0x310[ 10.364082] ? nla_reserve_64bit+0x21/0x40[ 10.364086] ? skb_free_head+0x65/0x80[ 10.364089] ? security_sock_rcv_skb+0x2c/0x50[ 10.364094] ? __cond_resched+0x19/0x30[ 10.364097] ? kmem_cache_alloc_trace+0x15a/0x420[ 10.364100] rtnl_newlink+0x49/0x70This change fixes MTL_RXQ_DMA_MAP1 mask issue and channel/queuemapping warning.BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216195
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igc: Reinstate IGC_REMOVED logic and implement it properlyThe initially merged version of the igc driver code (via commit146740f9abc4, "igc: Add support for PF") contained the followingIGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; }And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0)E.g. igb has similar checks in its MMIO accessors, and has a similarmacro E1000_REMOVED, which is implemented as follows: #define E1000_REMOVED(h) unlikely(!(h))These checks serve to detect and take note of an 0xffffffff MMIO readreturn from the device, which can be caused by a PCIe link flap or someother kind of PCI bus error, and to avoid performing MMIO reads andwrites from that point onwards.However, the IGC_REMOVED macro was not originally implemented: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */This led to the IGC_REMOVED logic to be removed entirely in asubsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVEDfunction"), with the rationale that such checks matter only forvirtualization and that igc does not support virtualization -- but aPCIe device can become detached even without virtualization being inuse, and without proper checks, a PCIe bus error affecting an igcadapter will lead to various NULL pointer dereferences, as the firstaccess after the error will set hw->hw_addr to NULL, and subsequentaccesses will blindly dereference this now-NULL pointer.This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), andimplements IGC_REMOVED the way it is done for igb, by checking for theunlikely() case of hw_addr being NULL. This change prevents the oopsesseen when a PCIe link flap occurs on an igc adapter.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()Yang Jihing reported a race between perf_event_set_output() andperf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list)After this; e1 is attached to an unmapped rb and a subsequentperf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } }The loop in perf_mmap_close() holds e2->mmap_mutex, while the attachin perf_event_set_output() holds e1->mmap_mutex. As such there is noserialization to avoid this race.Change perf_event_set_output() to take both e1->mmap_mutex ande2->mmap_mutex to alleviate that problem. Additionally, have the loopin perf_mmap() detach the rb directly, this avoids having to wait forthe concurrent perf_mmap_close() to get around to doing it to makeprogress.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/speculation: Fill RSB on vmexit for IBRSPrevent RSB underflow/poisoning attacks with RSB. While at it, add abunch of comments to attempt to document the current state of tribalknowledge about RSB attacks and what exactly is being mitigated.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/xive/spapr: correct bitmap allocation sizekasan detects access beyond the end of the xibm->bitmap allocation:BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140Read of size 8 at addr c00000001d1d0118 by task swapper/0/1CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28Call Trace:[c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable)[c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710[c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354[c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0[c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140[c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260[c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450[c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118[c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac[c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640[c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0[c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120)The buggy address belongs to the physical page:page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1dflags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff)raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc>c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fcThis happens because the allocation uses the wrong unit (bits) when itshould pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With smallnumbers of bits, the allocated object can be smaller than sizeof(long),which results in invalid accesses.Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired withbitmap_free() for consistency.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix kernel panic when creating VFWhen creating VFs a kernel panic can happen when calling toefx_ef10_try_update_nic_stats_vf.When releasing a DMA coherent buffer, sometimes, I don't know in whatspecific circumstances, it has to unmap memory with vunmap. It isdisallowed to do that in IRQ context or with BH disabled. Otherwise, wehit this line in vunmap, causing the crash: BUG_ON(in_interrupt());This patch reenables BH to release the buffer.Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix use after free when disabling sriovUse after free is detected by kfence when disabling sriov. What was readafter being freed was vf->pci_dev: it was freed from pci_disable_sriovand later read in efx_ef10_sriov_free_vf_vports, called fromefx_ef10_sriov_free_vf_vswitching.Set the pointer to NULL at release time to not trying to read it later.Reproducer and dmesg log (note that kfence doesn't detect it every time):$ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs$ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/selftests: fix subtraction overflow bugOn some machines hole_end can be small enough to cause subtractionoverflow. On the other side (addr + 2 * min_alignment) can overflowin case of mock tests. This patch should handle both cases.(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: Fix data-races around sysctl.While reading icmp sysctl variables, they can be changed concurrently.So, we need to add READ_ONCE() to avoid data-races.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: Fix data races in proc_douintvec_minmax().A sysctl variable is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.This patch changes proc_douintvec_minmax() to use READ_ONCE() andWRITE_ONCE() internally to fix data-races on the sysctl side. For now,proc_douintvec_minmax() itself is tolerant to a data-race, but we stillneed to add annotations on the other subsystem's side.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: Fix data races in proc_douintvec().A sysctl variable is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()internally to fix data-races on the sysctl side. For now, proc_douintvec()itself is tolerant to a data-race, but we still need to add annotations onthe other subsystem's side.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: Use separate src/dst nodes when preloading css_sets for migrationEach cset (css_set) is pinned by its tasks. When we're moving tasks aroundacross csets for a migration, we need to hold the source and destinationcsets to ensure that they don't go away while we're moving tasks about. Thisis done by linking cset->mg_preload_node on either themgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using thesame cset->mg_preload_node for both the src and dst lists was deemed okay asa cset can't be both the source and destination at the same time.Unfortunately, this overloading becomes problematic when multiple tasks areinvolved in a migration and some of them are identity noop migrations whileothers are actually moving across cgroups. For example, this can happen withthe following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procsthe process including the group leader back into a. In this final migration,non-leader threads would be doing identity migration while the group leaderis doing an actual one.After #3, let's say the whole process was in cset A, and that after #4, theleader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list.This means that A isn't held while migration is in progress. If all tasksleave A before the migration finishes and the incoming task pins it, thecset will be destroyed leading to use-after-free.This is caused by overloading cset->mg_preload_node for both src and dstpreload lists. We wanted to exclude the cset from the src list but ended upinadvertently excluding it from the dst list too.This patch fixes the issue by separating out cset->mg_preload_node into->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dstpreloadings don't interfere with each other.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queuexenvif_rx_next_skb() is expecting the rx queue not being empty, butin case the loop in xenvif_rx_action() is doing multiple iterations,the availability of another skb in the rx queue is not being checked.This can lead to crashes:[40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080[40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback][40072.537534] PGD 0 P4D 0[40072.537644] Oops: 0000 [#1] SMP NOPTI[40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5[40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021[40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000[40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback][40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246[40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7[40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8[40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008[40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708[40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0[40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000[40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033[40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660[40072.539211] Call Trace:[40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback][40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]Fix that by stopping the loop in case the rx queue becomes empty.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocateof_parse_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not needed anymore.Add missing of_node_put() in to fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: fix memory leak in error caseusbnet_write_cmd_async() mixed up which buffersneed to be freed in which error case.v2: add Fixes tagv3: fix uninitialized buf pointer
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_valsKuee reported a corner case where the tnum becomes constant after the callto __reg_bound_offset(), but the register's bounds are not, that is, itsmin bounds are still not equal to the register's max bounds.This in turn allows to leak pointers through turning a pointer register asis into an unknown scalar via adjust_ptr_min_max_vals().Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exitWhat can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, thatis, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off hasnot been done at that point via __update_reg_bounds(), which would have improvedthe umax to be equal to umin.Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()helper and use it consistently everywhere. After the fix, bounds have beencorrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the registeris regarded as a 'proper' constant scalar of 0.After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_open/close(): fix memory leakThe gs_usb driver appears to suffer from a malady common to many USBCAN adapter drivers in that it performs usb_alloc_coherent() toallocate a number of USB request blocks (URBs) for RX, and then laterrelies on usb_kill_anchored_urbs() to free them, but this doesn'tactually free them. As a result, this may be leaking DMA memory that'sbeen used by the driver.This commit is an adaptation of the techniques found in the esd_usb2driver where a similar design pattern led to a memory leak. Itexplicitly frees the RX URBs and their DMA memory via a call tousb_free_coherent(). Since the RX URBs were allocated in thegs_can_open(), we remove them in gs_can_close() rather than in thedisconnect function as was done in esd_usb2.For more information, see the 928150fad41b ("can: esd_usb2: fix memoryleak").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix use-after-free after 802.3ad slave unbindcommit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),resolve case, when there is several aggregation groups in the same bond.bond_3ad_unbind_slave will invalidate (clear) aggregator when__agg_active_ports return zero. So, ad_clear_agg can be executed even, whennum_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slavewill not update slave ports list, because lag_ports==NULL. So, here wegot slave ports, pointing to freed aggregator memory.Fix with checking actual number of ports in group (as was beforecommit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),before ad_clear_agg().The KASAN logs are as follows:[ 767.617392] ==================================================================[ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470[ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767[ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15[ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)[ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler[ 767.666468] Call trace:[ 767.668930] dump_backtrace+0x0/0x2d0[ 767.672625] show_stack+0x24/0x30[ 767.675965] dump_stack_lvl+0x68/0x84[ 767.679659] print_address_description.constprop.0+0x74/0x2b8[ 767.685451] kasan_report+0x1f0/0x260[ 767.689148] __asan_load2+0x94/0xd0[ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_eventsof_get_child_by_name() returns a node pointer with refcountincremented, we should use of_node_put() on it when done.This function only calls of_node_put() in normal path,missing it in error paths.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: unlink NAPI from device on destructionSyzbot found a race between tun file and device destruction.NAPIs live in struct tun_file which can get destroyed beforethe netdev so we have to del them explicitly. The currentcode is missing deleting the NAPI if the queue was detachedfirst.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm raid: fix KASAN warning in raid5_add_disksThere's a KASAN warning in raid5_add_disk when running the LVM testsuite.The warning happens in the testlvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warningby verifying that rdev->saved_raid_disk is within limits.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm raid: fix accesses beyond end of raid member arrayOn dm-raid table load (using raid_ctr), dm-raid allocates an arrayrs->devs[rs->raid_disks] for the raid device members. rs->raid_disksis defined by the number of raid metadata and image tupples passedinto the target's constructor.In the case of RAID layout changes being requested, that number can bedifferent from the current number of members for existing raid sets asdefined in their superblocks. Example RAID layout changes include:- raid1 legs being added/removed- raid4/5/6/10 number of stripes changed (stripe reshaping)- takeover to higher raid level (e.g. raid5 -> raid6)When accessing array members, rs->raid_disks must be used in controlloops instead of the potentially larger value in rs->md.raid_disks.Otherwise it will cause memory access beyond the end of the rs->devsarray.Fix this by changing code that is prone to out-of-bounds access.Also fix validate_raid_redundancy() to validate all devices that areadded. Also, use braces to help clean up raid_iterate_devices().The out-of-bounds memory accesses was discovered using KASAN.This commit was verified to pass all LVM2 RAID tests (with KASANenabled).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: fix xdp_rxq_info bug after suspend/resumeThe following sequence currently causes a driver bug warningwhen using virtio_net: # ip link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) # ip link set eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64 do_setlink+0x230/0xdd0 ...This happens because virtnet_freeze() frees the receive_queuecompletely (including struct xdp_rxq_info) but does not callxdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up thereceive_queue again but does not call xdp_rxq_info_reg().Actually, parts of virtnet_freeze_down() and virtnet_restore_up()are almost identical to virtnet_close() and virtnet_open(): onlythe calls to xdp_rxq_info_(un)reg() are missing. This means thatwe can fix this easily and avoid such problems in the future byjust calling virtnet_close()/open() from the freeze/restore handlers.Aside from adding the missing xdp_rxq_info calls the only differenceis that the refill work is only cancelled if netif_running(). However,this should not make any functional difference since the refill workshould only be active if the network interface is actually up.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intfof_graph_get_remote_node() returns remote device node pointer withrefcount incremented, we should use of_node_put() on itwhen not need anymore.Add missing of_node_put() to avoid refcount leak.Patchwork: https://patchwork.freedesktop.org/patch/488473/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add reserved GDT blocks checkWe capture a NULL pointer issue when resizing a corrupt ext4 image whichis freshly clear resize_inode feature (not run e2fsck). It could besimply reproduced by following steps. The problem is because of theresize_inode feature was cleared, and it will convert the filesystem tometa_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks wasnot reduced to zero, so could we mistakenly call reserve_backup_gdb()and passing an uninitialized resize_inode to it when adding new groupdescriptors. mkfs.ext4 /dev/sda 3G tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck mount /dev/sda /mnt resize2fs /dev/sda 8G ======== BUG: kernel NULL pointer dereference, address: 0000000000000028 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748 ... RIP: 0010:ext4_flex_group_add+0xe08/0x2570 ... Call Trace: ext4_resize_fs+0xbec/0x1660 __ext4_ioctl+0x1749/0x24e0 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xa6/0x110 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f2dd739617b ========The fix is simple, add a check in ext4_resize_begin() to make sure thatthe es->s_reserved_gdt_blocks is zero when the resize_inode feature isdisabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug_on ext4_mb_use_inode_paHulk Robot reported a BUG_ON:==================================================================kernel BUG at fs/ext4/mballoc.c:3211![...]RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f[...]Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0[...]==================================================================Above issue may happen as follows:-------------------------------------do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0);we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1`The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP.Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occurwhen the size is truncated. So start should be the start position ofthe group where ac_o_ex.fe_logical is located after alignment.In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUPis very large, the value calculated by start_off is more accurate.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm mirror log: round up region bitmap size to BITS_PER_LONGThe code in dm-log rounds up bitset_size to 32 bits. It then usesfind_next_zero_bit_le on the allocated region. find_next_zero_bit_leaccesses the bitmap using unsigned long pointers. So, on 64-bitarchitectures, it may access 4 bytes beyond the allocated size.Fix this bug by rounding up bitset_size to BITS_PER_LONG.This bug was found by running the lvm2 testsuite with kasan.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed tofsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed infsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_iotriggers KASAN use-after-free. To avoid the use-after-free, keep thereference to mc->root_mc_bus_dev->mc_io in a local variable and pass tofsl_destroy_mc_io().This patch needs rework to apply to kernels older than v5.15.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc2: Fix memory leak in dwc2_hcd_initusb_create_hcd will alloc memory for hcd, and we shouldcall usb_put_hcd to free it when platform_get_resource()fails to prevent memory leak.goto error2 label instead error1 to fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitionsof_find_node_by_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix call trace in setup_tx_descriptorsAfter PF reset and ethtool -t there was call trace in dmesgsometimes leading to panic. When there was some time, around 5seconds, between reset and test there were no errors.Problem was that pf reset calls i40e_vsi_close in prep_for_resetand ethtool -t calls i40e_vsi_close in diag_test. If there was notenough time between those commands the second i40e_vsi_close startsbefore previous i40e_vsi_close was done which leads to crash.Add check to diag_test if pf is in reset and don't start offlinetests if it is true.Add netif_info("testing failed") into unhappy path of i40e_diag_test()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()In an unlikely (and probably wrong?) case that the 'ppi' parameter ofata_host_alloc_pinfo() points to an array starting with a NULL pointer,there's going to be a kernel oops as the 'pi' local variable won't getreassigned from the initial value of NULL. Initialize 'pi' instead to'&ata_dummy_port_info' to fix the possible kernel oops for good...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNCThere is a small race window at snd_pcm_oss_sync() that is called fromOSS PCM SNDCTL_DSP_SYNC ioctl; namely the function callssnd_pcm_oss_make_ready() at first, then takes the params_lock mutexfor the rest. When the stream is set up again by another threadbetween them, it leads to inconsistency, and may result in unexpectedresults such as NULL dereference of OSS buffer as a fuzzer spottedrecently.The fix is simply to cover snd_pcm_oss_make_ready() call into the sameparams_lock mutex with snd_pcm_oss_make_ready_locked() variant.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds readsThis patch fixes slab-out-of-bounds reads in brcmfmac that occur inbrcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the countvalue of channel specifications provided by the device is greater thanthe length of 'list->element[]', decided by the size of the 'list'allocated with kzalloc(). The patch adds checks that make the functionsfree the buffer and return -EINVAL if that is the case. Note that thenegative return is handled by the caller, brcmf_setup_wiphybands() orbrcmf_cfg80211_attach().Found by a modified version of syzkaller.Crash Report from brcmf_construct_chaninfo():==================================================================BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_setup_wiphybands+0x1238/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_setup_wiphybands+0x290/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1536 bytes inside of 2048-byte region [ffff888115f24000, ffff888115f24800)Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc==================================================================Crash Report from brcmf_enable_bw40_2g():==========---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: use casting of u64 in clock multiplication to avoid overflowIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflowby depending on the values of the given parameters including the ic_clk.For example in our use case where ic_clk is larger than one million,multiplication of ic_clk * 4700 will result in 32 bit overflow.Add cast of u64 to the calculation to avoid multiplication overflow, anduse the corresponding define for divide.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:w1: fix WARNING after calling w1_process()I got the following WARNING message while removing driver(ds2482):------------[ cut here ]------------do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire]WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307RIP: 0010:__might_sleep+0x98/0xa0Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),set it to TASK_RUNNING when it breaks out of the loop to avoid thewarning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: Fix double increment of client_count in dma_chan_get()The first time dma_chan_get() is called for a channel the channelclient_count is incorrectly incremented twice for public channels,first in balance_ref_count(), and again prior to returning. Thisresults in an incorrect client count which will lead to thechannel resources not being freed when they should be. A simple test of repeated module load and unload of async_tx on a Dell Power Edge R7425 also shows this resulting in a kref underflow warning.[ 124.329662] async_tx: api initialized (async)[ 129.000627] async_tx: api initialized (async)[ 130.047839] ------------[ cut here ]------------[ 130.052472] refcount_t: underflow; use-after-free.[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28refcount_warn_saturate+0xba/0x110[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msrintel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvmmgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_sisyscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fopsk10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfatfat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmullibahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sasi40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hashdm_log dm_mod [last unloaded: async_tx][ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Nottainted 5.14.0-185.el9.x86_64 #1[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS1.18.0 01/17/2022[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4abd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff48 c7[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)knlGS:0000000000000000[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0[ 130.219729] Call Trace:[ 130.222192] [ 130.224305] dma_chan_put+0x10d/0x110[ 130.227988] dmaengine_put+0x7a/0xa0[ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280[ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0[ 130.242652] do_syscall_64+0x5c/0x90[ 130.246240] ? exc_page_fault+0x62/0x150[ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 130.255243] RIP: 0033:0x7f6463a3f5ab[ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 4883 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 0000 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 8901 48[ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:00000000000000b0[ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab[ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8[ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000[ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8[ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8[ 130.320875] [ 130.323081] ---[ end trace eff7156d56b5cf25 ]---cat /sys/class/dma/dma0chan*/in_use would get the wrong result.222Test-by: Jie Hai
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always report error in run_one_delayed_ref()Currently we have a btrfs_debug() for run_one_delayed_ref() failure, butif end users hit such problem, there will be no chance thatbtrfs_debug() is enabled. This can lead to very little useful info fordebugging.This patch will:- Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod- Replace the btrfs_debug() with btrfs_err()- Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller.This error should only be triggered at most once.As if run_one_delayed_ref() failed, we trigger the error message, thencausing the call chain to error out:btrfs_run_delayed_refs()`- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref()And we will abort the current transaction in btrfs_run_delayed_refs().If we have to run delayed refs for the abort transaction,run_one_delayed_ref() will just cleanup the refs and do nothing, thus nonew error messages would be output.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent bpf program recursion for raw tracepoint probesWe got report from sysbot [1] about warnings that were caused bybpf program attached to contention_begin raw tracepoint triggeringthe same tracepoint by using bpf_trace_printk helper that takestrace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ...The can be reproduced by attaching bpf program as raw tracepoint oncontention_begin tracepoint. The bpf prog calls bpf_trace_printkhelper. Then by running perf bench the spin lock code is forced totake slow path and call contention_begin tracepoint.Fixing this by skipping execution of the bpf program if it'salready running, Using bpf prog 'active' field, which is beingcurrently used by trampoline programs for the same reason.Moving bpf_prog_inc_misses_counter to syscall.c becausetrampoline.c is compiled in just for CONFIG_BPF_JIT option.[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p: trans_fd/p9_conn_cancel: drop client lock earliersyzbot reported a double-lock here and we no longer need thislock after requests have been moved off to local list:just drop the lock earlier.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Check sb_bsize_shift after reading superblockFuzzers like to scribble over sb_bsize_shift but in reality it's veryunlikely that this field would be corrupted on its own. Nevertheless itshould be checked to avoid the possibility of messy mount errors due tobad calculations. It's always a fixed value based on the block size sowe can just check that it's the expected value.Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test doneBefore this patch we get a withdraw after[ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block[ 76.413681] bh = 19 (type: exp=5, found=4)[ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492and with UBSAN configured we also get complaints like[ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19[ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'After the patch, these complaints don't appear, mount fails immediatelyand we get an explanation in dmesg.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm ioctl: fix misbehavior if list_versions races with module loading__list_versions will first estimate the required space using the"dm_target_iterate(list_version_get_needed, &needed)" call and then willfill the space using the "dm_target_iterate(list_version_get_info,&iter_info)" call. Each of these calls locks the targets using the"down_read(&_lock)" and "up_read(&_lock)" calls, however between the firstand second "dm_target_iterate" there is no lock held and the targetmodules can be loaded at this point, so the second "dm_target_iterate"call may need more space than what was the first "dm_target_iterate"returned.The code tries to handle this overflow (see the beginning oflist_version_get_info), however this handling is incorrect.The code sets "param->data_size = param->data_start + needed" and"iter_info.end = (char *)vers+len" - "needed" is the size returned by thefirst dm_target_iterate call; "len" is the size of the buffer allocated byuserspace."len" may be greater than "needed"; in this case, the code will write upto "len" bytes into the buffer, however param->data_size is set to"needed", so it may write data past the param->data_size value. The ioctlinterface copies only up to param->data_size into userspace, thus part ofthe result will be truncated.Fix this bug by setting "iter_info.end = (char *)vers + needed;" - thisguarantees that the second "dm_target_iterate" call will write only up tothe "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if itoverflows the "needed" space - in this case, userspace will allocate alarger buffer and retry.Note that there is also a bug in list_version_get_needed - we need to add"strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()snd_usbmidi_output_open() has a check of the NULL port withsnd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened,but in reality, the NULL port may be seen when the device gives aninvalid endpoint setup at the descriptor, hence the driver skips theallocation. That is, the check itself is valid and snd_BUG_ON()should be dropped from there. Otherwise it's confusing as if it werea real bug, as recently syzbot stumbled on it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: Fix error handling in ena_init()The ena_init() won't destroy workqueue created bycreate_singlethread_workqueue() when pci_register_driver() failed.Call destroy_workqueue() when pci_register_driver() failed to prevent theresource leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-transport: fix double ata_host_put() in ata_tport_add()In the error path in ata_tport_add(), when calling put_device(),ata_tport_release() is called, it will put the refcount of 'ap->host'.And then ata_host_put() is called again, the refcount is decreasedto 0, ata_host_release() is called, all ports are freed and set tonull.When unbinding the device after failure, ata_host_stop() is calledto release the resources, it leads a null-ptr-deref(), because allthe ports all freed and null.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : ata_host_stop+0x3c/0x84 [libata]lr : release_nodes+0x64/0xd0Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci]Fix this by removing redundant ata_host_put() in the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: fix potential memleak in 'add_widget_node'As 'kobject_add' may allocated memory for 'kobject->name' when return error.And in this function, if call 'kobject_add' failed didn't free kobject.So call 'kobject_put' to recycling resources.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()We got a syzkaller problem because of aarch64 alignment faultif KFENCE enabled. When the size from user bpf program is an oddnumber, like 399, 407, etc, it will cause the struct skb_shared_info'sunaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381To fix the problem, we adjust @size so that (@size + @hearoom) is amultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_infois aligned to a cache line.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: core: Fix use-after-free in snd_soc_exit()KASAN reports a use-after-free:BUG: KASAN: use-after-free in device_del+0xb5b/0xc60Read of size 8 at addr ffff888008655050 by task rmmod/387CPU: 2 PID: 387 Comm: rmmodHardware name: QEMU Standard PC (i440FX + PIIX, 1996)Call Trace:dump_stack_lvl+0x79/0x9aprint_report+0x17f/0x47bkasan_report+0xbb/0xf0device_del+0xb5b/0xc60platform_device_del.part.0+0x24/0x200platform_device_unregister+0x2e/0x40snd_soc_exit+0xa/0x22 [snd_soc_core]__do_sys_delete_module.constprop.0+0x34f/0x5b0do_syscall_64+0x3a/0x90entry_SYSCALL_64_after_hwframe+0x63/0xcd...It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,but its ret is ignored, which makes soc_dummy_dev unregistered twice.snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success...snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second timeTo fix it, handle error and stop snd_soc_init() when util_init() fail.Also clean debugfs when util_init() or driver_register() fail.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Fix a slab-out-of-bounds write bug in udf_find_entry()Syzbot reported a slab-out-of-bounds Write bug:loop0: detected capacity change from 0 to 2048==================================================================BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0fs/udf/namei.c:253Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0Hardware name: Google Compute Engine/Google Compute Engine, BIOSGoogle 10/11/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7ffab0d164d9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 3610: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900)The buggy address belongs to the physical page:page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000index:0x0 pfn:0x123fehead:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as allocatedpage last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 create_dummy_stack mm/page_owner.c:---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: macvlan: fix memory leaks of macvlan_common_newlinkkmemleak reports memory leaks in macvlan_common_newlink, as follows: ip link add link eth0 name .. type macvlan mode source macaddr add kmemleak reports:unreferenced object 0xffff8880109bb140 (size 64): comm "ip", pid 284, jiffies 4294986150 (age 430.108s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk backtrace: [] kmem_cache_alloc_trace+0x1c7/0x300 [] macvlan_hash_add_source+0x45/0xc0 [] macvlan_changelink_sources+0xd7/0x170 [] macvlan_common_newlink+0x38c/0x5a0 [] macvlan_newlink+0xe/0x20 [] __rtnl_newlink+0x7af/0xa50 [] rtnl_newlink+0x48/0x70 ...In the scenario where the macvlan mode is configured as 'source',macvlan_changelink_sources() will be execured to reconfigure list ofremote source mac addresses, at the same time, if register_netdevice()return an error, the resource generated by macvlan_changelink_sources()is not cleaned up.Using this patch, in the case of an error, it will executemacvlan_flush_sources() to ensure that the resource is cleaned up.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()A clk_prepare_enable() call in the probe is not balanced by a correspondingclk_disable_unprepare() in the remove function.Add the missing call.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_headerThis is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-valuein tipc_nl_compat_name_table_dump") where it should have type castedsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negativevalue.syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to networkWhen copying a `struct ifaddrlblmsg` to the network, __ifal_reservedremained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at: slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398 __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954 __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437 __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ...This patch ensures that the reserved field is always initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: Fix memory leaks of napi_get_fragskmemleak reports after running test_progs:unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe issue occurs in the following scenarios:tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del()...tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaksTo fix, add napi_complete() after napi_gro_frags().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix panic on frag_list with mixed head alloc typesSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat whensplitting gso_size mangled skb having linear-headed frag_list"), it isallowed to change gso_size of a GRO packet. However, that commit assumesthat "checking the first list_skb member suffices; i.e if either of thelist_skb members have non head_frag head, then the first one has too".It turns out this assumption does not hold. We've seen BUG_ON being hitin skb_segment when skbs on the frag_list had differing head_frag withthe vmxnet3 driver. This happens because __netdev_alloc_skb and__napi_alloc_skb can return a skb that is page backed or kmalloceddepending on the requested size. As the result, the last small skb inthe GRO packet can be kmalloced.There are three different locations where this can be fixed:(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list.(3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down.This patch implements (3). To limit the performance impact inskb_segment, the list is walked only for skbs with SKB_GSO_DODGY setthat have gso_size changed. Normal paths thus will not hit it.We could check only the last skb but since we need to walk the wholelist anyway, let's stay on the safe side.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hyperv: fix possible memory leak in mousevsc_probe()If hid_add_device() returns error, it should call hid_destroy_device()to free hid_dev which is allocated in hid_allocate_device().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queuesWhen running `test_sockmap` selftests, the following warning appears: WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root case is in commit 84472b436e76 ("bpf, sockmap: Fix more unchargedwhile msg has more_data"), where I used msg->sg.size to replace the tosend,causing breakage: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes;
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix BUG_ON() when directory entry has invalid rec_lenThe rec_len field in the directory entry has to be a multiple of 4. Acorrupted filesystem image can be used to hit a BUG() inext4_rec_len_to_disk(), called from make_indexed_dir(). ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Call Trace: ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0The fix simply adds a call to ext4_check_dir_entry() to validate thedirectory entry, returning -EFSCORRUPTED if the entry is invalid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix memory leak in query_regdb_file()In the function query_regdb_file() the alpha2 parameter is duplicatedusing kmemdup() and subsequently freed in regdb_fw_cb(). However,request_firmware_nowait() can fail without calling regdb_fw_cb() andthus leak memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()On some machines the number of listed CPUs may be bigger than the actualCPUs that exist. The tracing subsystem allocates a per_cpu directory withaccess to the per CPU ring buffer via a cpuX file. But to save space, thering buffer will only allocate buffers for online CPUs, even though theCPU array will be as big as the nr_cpu_ids.With the addition of waking waiters on the ring buffer when closing thefile, the ring_buffer_wake_waiters() now needs to make sure that thebuffer is allocated (with the irq_work allocated with it) before trying towake waiters, as it will cause a NULL pointer dereference.While debugging this, I added a NULL check for the buffer itself (which isOK to do), and also NULL pointer checks against buffer->buffers (which isnot fine, and will WARN) as well as making sure the CPU number passed inis within the nr_cpu_ids (which is also not fine if it isn't).Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix use-after-free for dynamic ftrace_opsKASAN reported a use-after-free with ftrace ops [1]. It was found fromvmcore that perf had registered two ops with the same contentsuccessively, both dynamic. After unregistering the second ops, ause-after-free occurred.In ftrace_shutdown(), when the second ops is unregistered, theFTRACE_UPDATE_CALLS command is not set because there is another enabledops with the same content. Also, both ops are dynamic and the ftracecallback function is ftrace_ops_list_func, so theFTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the valueof 'command' will be 0 and ftrace_shutdown() will skip the rcusynchronization.However, ftrace may be activated. When the ops is released, another CPUmay be accessing the ops. Add the missing synchronization to fix thisproblem.[1]BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...]Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...]Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix tree mod log mishandling of reallocated nodesWe have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n);This occurs because we replay the nodes in order that they happened, andwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,starting at 0. 'n' here is the number of items in this block, which inthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.The actual root cause of this was that we were replaying operations fora block that shouldn't have been replayed. Consider the followingsequence of events1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots.3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node.4. We modify a new root, and re-allocate the above node to the root node of this other root.The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8>From here the bug is triggered by the following steps1. Call btrfs_get_old_root() on the new_root.2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0.3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE.4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Free rwi on reset successFree the rwi structure in the event that the last rwi in the listprocessed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic:retry reset if there are no other resets") introduces an issue thatresults in a 32 byte memory leak whenever the last rwi in the listgets processed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mdio: fix undefined behavior in bit shift for __mdiobus_registerShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sduFix the race condition between the following two flows that run inparallel:1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> __sock_queue_rcv_skb.2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.An SKB can be queued by the first flow and immediately dequeued andfreed by the second flow, therefore the callers of l2cap_reassemble_sducan't use the SKB after that function returns. However, some placescontinue accessing struct l2cap_ctrl that resides in the SKB's CB for ashort time after l2cap_reassemble_sdu returns, leading to ause-after-free condition (the stack trace is below, line numbers forkernel 5.19.8).Fix it by keeping a local copy of struct l2cap_ctrl.BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetoothRead of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169Workqueue: hci0 hci_rx_work [bluetooth]Call Trace: dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth ret_from_fork (arch/x86/entry/entry_64.S:306) Allocated by task 43169: kasan_save_stack (mm/kasan/common.c:39) __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) __alloc_skb (net/core/skbuff.c:414) l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth process_one_work (kernel/workqueue.c:2289) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437) kthread (kernel/kthread.c:376) ret_from_fork (arch/x86/entry/entry_64.S:306)Freed by task 27920: kasan_save_stack (mm/kasan/common.c:39) kasan_set_track (mm/kasan/common.c:45) kasan_set_free_info (mm/kasan/generic.c:372) ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328) slab_free_freelist_hook (mm/slub.c:1780) kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553) skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth sock_read_iter (net/socket.c:1087) new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401) vfs_read (fs/read_write.c:482) ksys_read (fs/read_write.c:620) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at find_parent_nodes()During backref walking, at find_parent_nodes(), if we are dealing with adata extent and we get an error while resolving the indirect backrefs, atresolve_indirect_refs(), or in the while loop that iterates over the refsin the direct refs rbtree, we end up leaking the inode lists attached tothe direct refs we have in the direct refs rbtree that were not yet addedto the refs ulist passed as argument to find_parent_nodes(). Since theywere not yet added to the refs ulist and prelim_release() does not freethe lists, on error the caller can only free the lists attached to therefs that were added to the refs ulist, all the remaining refs get theirinode lists never freed, therefore leaking their memory.Fix this by having prelim_release() always free any attached inode listto each ref found in the rbtree, and have find_parent_nodes() set theref's inode list to NULL once it transfers ownership of the inode listto a ref added to the refs ulist passed to find_parent_nodes().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at resolve_indirect_refs()During backref walking, at resolve_indirect_refs(), if we get an errorwe jump to the 'out' label and call ulist_free() on the 'parents' ulist,which frees all the elements in the ulist - however that does not freeany inode lists that may be attached to elements, through the 'aux' fieldof a ulist node, so we end up leaking lists if we have any attached tothe unodes.Fix this by calling free_leaf_list() instead of ulist_free() when we exitfrom resolve_indirect_refs(). The static function free_leaf_list() ismoved up for this to be possible and it's slightly simplified by removingunnecessary code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: fix possible memory leak in mISDN_register_device()Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device'sbus_id string array"), the name of device is allocated dynamically,add put_device() to give up the reference, so that the name can befreed in kobject_cleanup() when the refcount is 0.Set device class before put_device() to avoid null release() functionWARN message in device_release().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix WARNING in ip_vs_app_net_cleanup()During the initialization of ip_vs_app_net_init(), if file ip_vs_appfails to be created, the initialization is successful by default.Therefore, the ip_vs_app file doesn't be found during the remove inip_vs_app_net_cleanup(). It will cause WRNING.The following is the stack information:name 'ip_vs_app'WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460Call Trace:ops_exit_list+0x125/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: Fix use after free in red_enqueue()We can't use "skb" again after passing it to qdisc_enqueue(). This isbasically identical to commit 2f09707d0c97 ("sch_sfb: Also store skblen before calling child enqueue").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skbshould be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()will only free skb when i2c_master_send() return >=0, which means skbwill memleak when i2c_master_send() failed. Free skb no matter whetheri2c_master_send() succeeds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb whennxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As theresult, the skb will memleak. nxp_nci_send() should also free the skbwhen nxp_nci_i2c_write() succeeds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: fdp: Fix potential memory leak in fdp_nci_send()fdp_nci_send() will call fdp_nci_i2c_write that will not free skb inthe function. As a result, when fdp_nci_i2c_write() finished, the skbwill memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()finished.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix null-ptr-deref in ib_core_cleanup()KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ...It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wqFix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs4: Fix kmemleak when allocate slot failedIf one of the slot allocate failed, should cleanup all the otherallocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Correctly move list in sc_disable()Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")incorrectly tries to move a list from one list head to another. Theresult is a kernel crash.The crash is triggered when a link goes down and there are waiters for asend to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30The fix is to use the correct call to move the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Prevent nested device-reset callsAutomatic kernel fuzzing revealed a recursive locking violation inusb-storage:============================================WARNING: possible recursive locking detected5.18.0 #3 Not tainted--------------------------------------------kworker/1:3/1205 is trying to acquire lock:ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230but task is already holding lock:ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230...stack backtrace:CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.13.0-1ubuntu1.1 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace:__dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]check_deadlock kernel/locking/lockdep.c:3031 [inline]validate_chain kernel/locking/lockdep.c:3816 [inline]__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053lock_acquire kernel/locking/lockdep.c:5665 [inline]lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630__mutex_lock_common kernel/locking/mutex.c:603 [inline]__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458device_remove drivers/base/dd.c:545 [inline]device_remove+0x11f/0x170 drivers/base/dd.c:537__device_release_driver drivers/base/dd.c:1222 [inline]device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114This turned out not to be an error in usb-storage but rather a nesteddevice reset attempt. That is, as the rtl8712 driver was beingunbound from a composite device in preparation for an unrelated USBreset (that driver does not have pre_reset or post_reset callbacks),its ->remove routine called usb_reset_device() -- thus nesting onereset call within another.Performing a reset as part of disconnect processing is a questionablepractice at best. However, the bug report points out that the USBcore does not have any protection against nested resets. Adding areset_in_progress flag and testing it will prevent such errors in thefuture.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vt: Clear selection before changing the fontWhen changing the console font with ioctl(KDFONTOP) the new font sizecan be bigger than the previous font. A previous selection may thus nowbe outside of the new screen size and thus trigger out-of-boundsaccesses to graphics memory if the selection is removed invc_do_resize().Prevent such out-of-memory accesses by dropping the selection before thevarious con_font_set() console handlers are called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flagsyzbot is reporting hung task at __input_unregister_device() [1], foriforce_close() waiting at wait_event_interruptible() with dev->mutex heldis blocking input_disconnect_device() from __input_unregister_device().It seems that the cause is simply that commit c2b27ef672992a20 ("Input:iforce - wait for command completion when closing the device") forgot tocall wake_up() after clear_bit().Fix this problem by introducing a helper that calls clear_bit() followedby wake_up_all().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8712: fix use after free bugs_Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()functions don't do anything except free the "pcmd" pointer. Itresults in a use after free. Delete them.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: fix strp_init() order and cleanupstrp_init() is called just a few lines above this csk->sk_user_datacheck, it also initializes strp->work etc., therefore, it isunnecessary to call strp_done() to cancel the freshly initializedwork.And if sk_user_data is already used by KCM, psock->strp should not betouched, particularly strp->work state, so we need to move strp_init()after the csk->sk_user_data check.This also makes a lockdep warning reported by syzbot go away.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a data-race around bpf_jit_limit.While reading bpf_jit_limit, it can be changed concurrently via sysctl,WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limitis long, so we need to add a paired READ_ONCE() to avoid load-tearing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: fb_pm2fb: Avoid potential divide by zero errorIn `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will becopied from user, then go through `fb_set_var()` and`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.Along the path, `var->pixclock` won't be modified. This function checkswhether reciprocal of `var->pixclock` is too high. If `var->pixclock` iszero, there will be a divide by zero error. So, it is necessary to checkwhether denominator is zero to avoid crash. As this bug is found bySyzkaller, logs are listed below.divide error in pm2fb_check_varCall Trace: fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hidraw: fix memory leak in hidraw_release()Free the buffered reports before deleting the list entry.BUG: memory leakunreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemdup+0x23/0x50 mm/util.c:128 [] kmemdup include/linux/fortify-string.h:440 [inline] [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [] expire_timers kernel/time/timer.c:1519 [inline] [] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [] __run_timers kernel/time/timer.c:1768 [inline] [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [] invoke_softirq kernel/softirq.c:445 [inline] [] __irq_exit_rcu kernel/softirq.c:650 [inline] [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wqstorvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as itdoesn't need to make forward progress under memory pressure. Marking thisworkqueue as WQ_MEM_RECLAIM may cause deadlock while flushing anon-WQ_MEM_RECLAIM workqueue. In the current state it causes the followingwarning:[ 14.506347] ------------[ cut here ]------------[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip->[ 14.506408] Call Trace:[ 14.506412] __flush_work+0xf1/0x1c0[ 14.506414] __cancel_work_timer+0x12f/0x1b0[ 14.506417] ? kernfs_put+0xf0/0x190[ 14.506418] cancel_delayed_work_sync+0x13/0x20[ 14.506420] disk_block_events+0x78/0x80[ 14.506421] del_gendisk+0x3d/0x2f0[ 14.506423] sr_remove+0x28/0x70[ 14.506427] device_release_driver_internal+0xef/0x1c0[ 14.506428] device_release_driver+0x12/0x20[ 14.506429] bus_remove_device+0xe1/0x150[ 14.506431] device_del+0x167/0x380[ 14.506432] __scsi_remove_device+0x11d/0x150[ 14.506433] scsi_remove_device+0x26/0x40[ 14.506434] storvsc_remove_lun+0x40/0x60[ 14.506436] process_one_work+0x209/0x400[ 14.506437] worker_thread+0x34/0x400[ 14.506439] kthread+0x121/0x140[ 14.506440] ? process_one_work+0x400/0x400[ 14.506441] ? kthread_park+0x90/0x90[ 14.506443] ret_from_fork+0x35/0x40[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: call __md_stop_writes in md_stopFrom the link [1], we can see raid1d was running even after the pathraid_dtr -> md_stop -> __md_stop.Let's stop write first in destructor to align with normal md-raid tofix the KASAN issue.[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390: fix double free of GS and RI CBs on fork() failureThe pointers for guarded storage and runtime instrumentation controlblocks are stored in the thread_struct of the associated task. Thesepointers are initially copied on fork() via arch_dup_task_struct()and then cleared via copy_thread() before fork() returns. If fork()happens to fail after the initial task dup and before copy_thread(),the newly allocated task and associated thread_struct memory arefreed via free_task() -> arch_release_task_struct(). This results ina double free of the guarded storage and runtime info structsbecause the fields in the failed task still refer to memoryassociated with the source task.This problem can manifest as a BUG_ON() in set_freepointer() (withCONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)when running trinity syscall fuzz tests on s390x. To avoid thisproblem, clear the associated pointer fields inarch_dup_task_struct() immediately after the new task is copied.Note that the RI flag is still cleared in copy_thread() because itresides in thread stack memory and that is where stack info iscopied.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: Check for overflow while configuring loopThe userspace can configure a loop using an ioctl call, whereina configuration of type loop_config is passed (see lo_ioctl()'scase on line 1550 of drivers/block/loop.c). This proceeds to callloop_configure() which in turn calls loop_set_status_from_info()(see line 1050 of loop.c), passing &config->info which is of typeloop_info64*. This function then sets the appropriate values, likethe offset.loop_device has lo_offset of type loff_t (see line 52 of loop.c),which is typdef-chained to long long, whereas loop_info64 haslo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).The function directly copies offset from info to the device asfollows (See line 980 of loop.c): lo->lo_offset = info->lo_offset;This results in an overflow, which triggers a warning in iomap_iter()due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos);Thus, check for negative value during loop_set_status_from_info().Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix refcount leak in __xfrm_policy_check()The issue happens on an error path in __xfrm_policy_check(). When thefetching process of the object `pols[1]` fails, the function simplyreturns 0, forgetting to decrement the reference count of `pols[0]`,which is incremented earlier by either xfrm_sk_policy_lookup() orxfrm_policy_lookup(). This may result in memory leaks.Fix it by decreasing the reference count of `pols[0]` in that path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: don't call disarm_kprobe() for disabled kprobesThe assumption in __disable_kprobe() is wrong, and it could try to disarman already disarmed kprobe and fire the WARN_ONCE() below. [0] We caneasily reproduce this issue.1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^CActually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() missessome cleanups and leaves the aggregated kprobe in the hash table. Then,__unregister_trace_kprobe() initialises tk->rp.kp.list and creates aninfinite loop like this. aggregated kprobe.list -> kprobe.list -. ^ | '.__.'In this situation, these commands fall into the infinite loop and resultin RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop.To avoid the issue, make sure we don't call disarm_kprobe() for disabledkprobes.[0]Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)Modules linked in: enaCPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffffRBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffffR10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64: Init jump labels before parse_early_param()On 64-bit, calling jump_label_init() in setup_feature_keys() is toolate because static keys may be used in subroutines ofparse_early_param() which is again subroutine of early_init_devtree().For example booting with "threadirqs": static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Call Trace: static_key_enable_cpuslocked+0xf8/0x120 (unreliable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214So call jump_label_init() just before parse_early_param() inearly_init_devtree().[mpe: Add call trace to change log and minor wording edits.]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix possible memory leak when failing to issue CMF WQEThere is no corresponding free routine if lpfc_sli4_issue_wqe fails toissue the CMF WQE in lpfc_issue_cmf_sync_wqe.If ret_val is non-zero, then free the iocbq request structure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: ohci-ppc-of: Fix refcount leak bugIn ohci_hcd_ppc_of_probe(), of_find_compatible_node() will returna node pointer with refcount incremented. We should use of_node_put()when it is not used anymore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pci: Fix get_phb_number() lockingThe recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEPwarning on some systems: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disabled at: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1 Call Trace: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64This is because pcibios_alloc_controller() holds hose_spinlock butof_alias_get_id() takes of_mutex which can sleep.The hose_spinlock protects the phb_bitmap, and also the hose_list, butit doesn't need to be held while get_phb_number() calls the OF routines,because those are only looking up information in the device tree.So fix it by having get_phb_number() take the hose_spinlock itself, onlywhere required, and then dropping the lock before returning.pcibios_alloc_controller() then needs to take the lock again before thelist_add() but that's safe, the order of the list is not important.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix adminq error handlingiavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherentmemory for VF mailbox.Free DMA regions for both ASQ and ARQ in case error happens duringconfiguration of ASQ/ARQ registers.Without this change it is possible to see when unloading interface:74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: fix memory leak inside XPD_TX with mergeableWhen we call xdp_convert_buff_to_frame() to get xdpf, if it returnsNULL, we should check if xdp_page was allocated by xdp_linearize_page().If it is newly allocated, it should be freed here alone. Just like anyother "goto err_xdp".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: fix aq_vec index out of range errorThe final update statement of the for loop exceeds the array range, thedereference of self->aq_vec[i] is not checked and then leads to theindex out of range error.Also fixed this kind of coding style in other for loop.[ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48[ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]'[ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2[ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022[ 97.937611] Workqueue: events_unbound async_run_entry_fn[ 97.937616] Call Trace:[ 97.937617] [ 97.937619] dump_stack_lvl+0x49/0x63[ 97.937624] dump_stack+0x10/0x16[ 97.937626] ubsan_epilogue+0x9/0x3f[ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 97.937629] ? __scm_send+0x348/0x440[ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic][ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic][ 97.937644] aq_suspend_common+0x88/0x90 [atlantic][ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic][ 97.937653] pci_pm_suspend+0x7e/0x1a0[ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0[ 97.937657] dpm_run_callback+0x54/0x190[ 97.937660] __device_suspend+0x14c/0x4d0[ 97.937661] async_suspend+0x23/0x70[ 97.937663] async_run_entry_fn+0x33/0x120[ 97.937664] process_one_work+0x21f/0x3f0[ 97.937666] worker_thread+0x4a/0x3c0[ 97.937668] ? process_one_work+0x3f0/0x3f0[ 97.937669] kthread+0xf0/0x120[ 97.937671] ? kthread_complete_and_exit+0x20/0x20[ 97.937672] ret_from_fork+0x22/0x30[ 97.937676] v2. fixed "warning: variable 'aq_vec' set but not used"v3. simplified a for loop
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: unset reloc control if transaction commit fails in prepare_to_relocate()In btrfs_relocate_block_group(), the rc is allocated. Thenbtrfs_relocate_block_group() callsrelocate_block_group() prepare_to_relocate() set_reloc_control()that assigns rc to the variable fs_info->reloc_ctl. Whenprepare_to_relocate() returns, it callsbtrfs_commit_transaction() btrfs_start_dirty_block_groups() btrfs_alloc_path() kmem_cache_zalloc()which may fail for example (or other errors could happen). When thefailure occurs, btrfs_relocate_block_group() detects the error and freesrc and doesn't set fs_info->reloc_ctl to NULL. After that, inbtrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl andthen used, which may cause a use-after-free bug.This possible bug can be triggered by calling btrfs_ioctl_balance()before calling btrfs_ioctl_defrag().To fix this possible bug, in prepare_to_relocate(), check ifbtrfs_commit_transaction() fails. If the failure occurs,unset_reloc_control() is called to set fs_info->reloc_ctl to NULL.The error log in our fault-injection testing is shown as follows: [ 58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs] ... [ 58.753577] Call Trace: ... [ 58.755800] kasan_report+0x45/0x60 [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs] [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs] [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs] [ 58.758231] start_transaction+0x896/0x2950 [btrfs] [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs] [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs] [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs] ... [ 58.768510] Allocated by task 23683: [ 58.768777] ____kasan_kmalloc+0xb5/0xf0 [ 58.769069] __kmalloc+0x227/0x3d0 [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs] [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs] [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ... [ 58.773337] Freed by task 23683: ... [ 58.774815] kfree+0xda/0x2b0 [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs] [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs] [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is nullFixes a NULL pointer derefence bug triggered from tap driver.When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null(in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb)virtio_net_hdr_to_skb calls dev_parse_header_protocol whichneeds skb->dev field to be valid.The line that trigers the bug is in dev_parse_header_protocol(dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%raxSetting skb->dev before the call in tap.c fixes the issue.BUG: kernel NULL pointer dereference, address: 0000000000000230RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: add overflow check in register_shm_helper()With special lengths supplied by user space, register_shm_helper() hasan integer overflow when calculating the number of pages covered by asupplied user space memory region.This causes internal_get_user_pages_fast() a helper function ofpin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114Fix this by adding an an explicit call to access_ok() intee_shm_register_user_buf() to catch an invalid user space addressearly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm raid: fix address sanitizer warning in raid_statusThere is this warning when using a kernel with the address sanitizerand running this testsuite:https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid==================================================================BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3. #1Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011Call Trace: dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80The warning is caused by reading conf->max_nr_stripes in raid_status. Thecode in raid_status reads mddev->private, casts it to struct r5conf andreads the entry max_nr_stripes.However, if we have different raid type than 4/5/6, mddev->privatedoesn't point to struct r5conf; it may point to struct r0conf, structr1conf, struct r10conf or struct mpconf. If we cast a pointer to oneof these structs to struct r5conf, we will be reading invalid memoryand KASAN warns about it.Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/csd_lock: Change csdlock_debug from early_param to __setupThe csdlock_debug kernel-boot parameter is parsed by theearly_param() function csdlock_debug(). If set, csdlock_debug()invokes static_branch_enable() to enable csd_lock_wait feature, whichtriggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y andCONFIG_SPARSEMEM_VMEMMAP=n.With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called instatic_key_enable() and returns NULL, resulting in a NULL dereferencebecause mem_section is initialized only later in sparse_init().This is also a problem for powerpc because early_param() functionsare invoked earlier than jump_label_init(), also resulting instatic_key_enable() failures. These failures cause the warning "statickey 'xxx' used before call to jump_label_init()".Thus, early_param is too early for csd_lock_wait to runstatic_branch_enable(), so changes it to __setup to fix these.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: fix use-after-free crash in dm_sm_register_threshold_callbackFault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"If a metadata commit fails, the transaction will be aborted and themetadata space maps will be destroyed. If a DM table reload thenhappens for this failed thin-pool, a use-after-free will occur indm_sm_register_threshold_callback (called fromdm_pool_register_metadata_threshold).Fix this by in dm_pool_register_metadata_threshold() by returning the-EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()with a new error message: "Error registering metadata threshold".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)KASAN reports:[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)[ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0[ 4.683454][ T0][ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1[ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016[ 4.703196][ T0] Call Trace:[ 4.706334][ T0] [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)after converting the type of the first argument (@nr, bit number)of arch_test_bit() from `long` to `unsigned long`[0].Under certain conditions (for example, when ACPI NUMA is disabledvia command line), pxm_to_node() can return %NUMA_NO_NODE (-1).It is valid 'magic' number of NUMA node, but not valid bit numberto use in bitops.node_online() eventually descends to test_bit() without checkingfor the input, assuming it's on caller side (which might be goodfor perf-critical tasks). There, -1 becomes %ULONG_MAX which leadsto an insane array index when calculating bit position in memory.For now, add an explicit check for @node being not %NUMA_NO_NODEbefore calling test_bit(). The actual logics didn't change hereat all.[0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spmi: trace: fix stack-out-of-bound access in SPMI tracing functionstrace_spmi_write_begin() and trace_spmi_read_end() both callmemcpy() with a length of "len + 1". This leads to one extrabyte being read beyond the end of the specified buffer. Fixthis out-of-bound memory access by using a length of "len"instead.Here is a KASAN log showing the issue:BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314...Call trace: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ...addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]this frame has 1 object: [32, 33) 'status'Memory state around the buggy address: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00>ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00==================================================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: s3fb: Check the size of screen before memset_io()In the function s3fb_set_par(), the value of 'screen_size' iscalculated by the user input. If the user provides the improper value,the value of 'screen_size' may larger than 'info->screen_size', whichmay cause the following bug:[ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000[ 54.083742] #PF: supervisor write access in kernel mode[ 54.083744] #PF: error_code(0x0002) - not-present page[ 54.083760] RIP: 0010:memset_orig+0x33/0xb0[ 54.083782] Call Trace:[ 54.083788] s3fb_set_par+0x1ec6/0x4040[ 54.083806] fb_set_var+0x604/0xeb0[ 54.083836] do_fb_ioctl+0x234/0x670Fix the this by checking the value of 'screen_size' before memset_io().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeoutsEnsure SRB is returned during I/O timeout error escalation. If that is notpossible fail the escalation path.Following crash stack was seen:BUG: unable to handle kernel paging request at 0000002f56aa90f8IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: arkfb: Check the size of screen before memset_io()In the function arkfb_set_par(), the value of 'screen_size' iscalculated by the user input. If the user provides the improper value,the value of 'screen_size' may larger than 'info->screen_size', whichmay cause the following bug:[ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000[ 659.399077] #PF: supervisor write access in kernel mode[ 659.399079] #PF: error_code(0x0002) - not-present page[ 659.399094] RIP: 0010:memset_orig+0x33/0xb0[ 659.399116] Call Trace:[ 659.399122] arkfb_set_par+0x143f/0x24c0[ 659.399130] fb_set_var+0x604/0xeb0[ 659.399161] do_fb_ioctl+0x234/0x670[ 659.399189] fb_ioctl+0xdd/0x130Fix the this by checking the value of 'screen_size' before memset_io().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: vt8623fb: Check the size of screen before memset_io()In the function vt8623fb_set_par(), the value of 'screen_size' iscalculated by the user input. If the user provides the improper value,the value of 'screen_size' may larger than 'info->screen_size', whichmay cause the following bug:[ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000[ 583.339049] #PF: supervisor write access in kernel mode[ 583.339052] #PF: error_code(0x0002) - not-present page[ 583.339074] RIP: 0010:memset_orig+0x33/0xb0[ 583.339110] Call Trace:[ 583.339118] vt8623fb_set_par+0x11cd/0x21e0[ 583.339146] fb_set_var+0x604/0xeb0[ 583.339181] do_fb_ioctl+0x234/0x670[ 583.339209] fb_ioctl+0xdd/0x130Fix the this by checking the value of 'screen_size' before memset_io().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock()Since the user can control the arguments of the ioctl() from the userspace, under special arguments that may result in a divide-by-zero bugin: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul);with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0.and then in: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock);we'll get a division-by-zero.The following log can reveal it:divide error: 0000 [#1] PREEMPT SMP KASAN PTIRIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline]RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189Fix this by checking the argument of ark_set_pixclock() first.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowedWith cgroup v2, the cpuset's cpus_allowed mask can be empty indicatingthat the cpuset will just use the effective CPUs of its parent. Socpuset_can_attach() can call task_can_attach() with an empty mask.This can lead to cpumask_any_and() returns nr_cpu_ids causing the callto dl_bw_of() to crash due to percpu value access of an out of boundCPU value. For example: [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] cgroup_subtree_control_write+0x322/0x400 [80468.212854] kernfs_fop_write_iter+0x11c/0x1b0 [80468.213777] new_sync_write+0x11f/0x1b0 [80468.214689] vfs_write+0x1eb/0x280 [80468.215592] ksys_write+0x5f/0xe0 [80468.216463] do_syscall_64+0x5c/0x80 [80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xaeFix that by using effective_cpus instead. For cgroup v1, effective_cpusis the same as cpus_allowed. For v2, effective_cpus is the real cpumaskto be used by tasks within the cpuset anyway.Also update task_can_attach()'s 2nd argument name to cs_effective_cpus toreflect the change. In addition, a check is added to task_can_attach()to guard against the possibility that cpumask_any_and() may return avalue >= nr_cpu_ids.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/xive: Fix refcount leak in xive_get_max_prioof_find_node_by_path() returns a node pointer withrefcount incremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:video: fbdev: amba-clcd: Fix refcount leak bugsIn clcdfb_of_init_display(), we should call of_node_put() for thereferences returned by of_graph_get_next_endpoint() andof_graph_get_remote_port_parent() which have increased the refcount.Besides, we should call of_node_put() both in fail path or whenthe references are not used anymore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: fix deadlock and link starvation in outgoing data pathThe current implementation queues up new control and user packets as neededand processes this queue down to the ldisc in the same code path.That means that the upper and the lower layer are hard coupled in the code.Due to this deadlocks can happen as seen below while transmitting data,especially during ldisc congestion. Furthermore, the data channels starvethe control channel on high transmission load on the ldisc.Introduce an additional control channel data queue to prevent timeouts andlink hangups during ldisc congestion. This is being processed before theuser channel data queue in gsm_data_kick(), i.e. with the highest priority.Put the queue to ldisc data path into a workqueue and trigger it whenevernew data has been put into the transmission queue. Changegsm_dlci_data_sweep() accordingly to fill up the transmission queue untilTX_THRESH_HI. This solves the locking issue, keeps latency low and providesgood performance on high data load.Note that now all packets from a DLCI are removed from the internal queueif the associated DLCI was closed. This ensures that no data is sent by theintroduced write task to an already closed DLCI.BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40RIP: 0010:__do_softirq+0x83/0x34eCode: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2de2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 6180 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00RSP: 0018:ffffc90000003f98 EFLAGS: 00000286RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 asm_common_interrupt+0x1e/0x40RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 3d 97 33 ff65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f3e5e35c15cCode: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal abortedFollowing process will fail assertion 'jh->b_frozen_data == NULL' injbd2_journal_dirty_metadata(): jbd2_journal_commit_transactionunlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMITunlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // return false --> jbd2 abort <-- while (commit_transaction->t_buffers) if (is_journal_aborted) jbd2_journal_refile_buffer __jbd2_journal_refile_buffer WRITE_ONCE(jh->b_transaction, jh->b_next_transaction) WRITE_ONCE(jh->b_next_transaction, NULL) __jbd2_journal_file_buffer(jh, BJ_Reserved) J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure !The reproducer (See detail in [Link]) reports: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1629! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: unlink Tainted: G W 5.19.0-rc6-00115-g4a57a8400075-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Call Trace: __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80After journal aborting, __jbd2_journal_refile_buffer() is executed withholding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()'into the area protected by @jh->b_state_lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix error unwind in rxe_create_qp()In the function rxe_create_qp(), rxe_qp_from_init() is called toinitialize qp, internally things like the spin locks are not setup untilrxe_qp_init_req().If an error occures before this point then the unwind will callrxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()which will oops when trying to access the uninitialized spinlock.Move the spinlock initializations earlier before any failures.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hfi1: fix potential memory leak in setup_base_ctxt()setup_base_ctxt() allocates a memory chunk for uctxt->groups withhfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groupsis not released, which will lead to a memory leak.We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups()when init_user_ctxt() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr()__qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" withinit_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr"is released while "mr->info.pbl_table" is not released, which will leadto a memory leak.We should release the "mr->info.pbl_table" with qedr_free_pbl() when erroroccurs to fix the memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switchof_find_matching_node() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.of_node_put() checks null pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errorsIf dw_pcie_ep_init() fails to perform any action after the EPC memory isinitialized and the MSI memory region is allocated, the latter parts won'tbe undone thus causing a memory leak. Add a cleanup-on-error path to fixthese leaks.[bhelgaas: commit log]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix potential deadlock in __driver_attachIn __driver_attach function, There are also AA deadlock problem,like the commit b232b02bf3c2 ("driver core: fix deadlock in__device_attach").stack like commit b232b02bf3c2 ("driver core: fix deadlock in__device_attach").list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As above show, when it is allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute instead. it will lead to A-A deadlock because of __driver_attach_async_helper getting lock dev.Reproduce:and it can be reproduce by make the condition(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, likebelow:[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disablesthis message.[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:0 flags:0x00004000[ 370.788865] Call Trace:[ 370.789374] [ 370.789841] __schedule+0x482/0x1050[ 370.790613] schedule+0x92/0x1a0[ 370.791290] schedule_preempt_disabled+0x2c/0x50[ 370.792256] __mutex_lock.isra.0+0x757/0xec0[ 370.793158] __mutex_lock_slowpath+0x1f/0x30[ 370.794079] mutex_lock+0x50/0x60[ 370.794795] __device_driver_lock+0x2f/0x70[ 370.795677] ? driver_probe_device+0xd0/0xd0[ 370.796576] __driver_attach_async_helper+0x1d/0xd0[ 370.797318] ? driver_probe_device+0xd0/0xd0[ 370.797957] async_schedule_node_domain+0xa5/0xc0[ 370.798652] async_schedule_node+0x19/0x30[ 370.799243] __driver_attach+0x246/0x290[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0[ 370.800548] bus_for_each_dev+0x9d/0x130[ 370.801132] driver_attach+0x22/0x30[ 370.801666] bus_add_driver+0x290/0x340[ 370.802246] driver_register+0x88/0x140[ 370.802817] ? virtio_scsi_init+0x116/0x116[ 370.803425] scsi_register_driver+0x1a/0x30[ 370.804057] init_sd+0x184/0x226[ 370.804533] do_one_initcall+0x71/0x3a0[ 370.805107] kernel_init_freeable+0x39a/0x43a[ 370.805759] ? rest_init+0x150/0x150[ 370.806283] kernel_init+0x26/0x230[ 370.806799] ret_from_fork+0x1f/0x30To fix the deadlock, move the async_schedule_dev outside device_lock,as we can see, in async_schedule_node_domain, the parameter ofqueue_work_node is system_unbound_wq, so it can accept concurrentoperations. which will also not change the code logic, and willnot lead to deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probeof_parse_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: Fix refcount leak in ehci_hcd_ppc_of_probeof_find_compatible_node() returns a node pointer with refcountincremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: Fix possible refcount leak in if_usb_probe()usb_get_dev will be called before lbs_get_firmware_async which means thatusb_put_dev need to be called when lbs_get_firmware_async fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: When HCI work queue is drained, only queue chained workThe HCI command, event, and data packet processing workqueue is drainedto avoid deadlock in commit76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").There is another delayed work, which will queue command to this drainedworkqueue. Which results in the following error report:Bluetooth: hci2: command 0x040f tx timeoutWARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140Workqueue: events hci_cmd_timeoutRIP: 0010:__queue_work+0xdad/0x1140RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue thetimeout workqueue while command workqueue is draining.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Fix global state lock backoffWe need to grab the lock after the early return for !hwpipe case.Otherwise, we could have hit contention yet still returned 0.Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flaggedin CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0Patchwork: https://patchwork.freedesktop.org/patch/492701/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ath9k: fix use-after-free in ath9k_hif_usb_rx_cbSyzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. Theproblem was in incorrect htc_handle->drv_priv initialization.Probable call trace which can trigger use-after-free:ath9k_htc_probe_device() /* htc_handle->drv_priv = priv; */ ath9k_htc_wait_for_target() <--- Failed ieee80211_free_hw() <--- priv pointer is freed...ath9k_hif_usb_rx_cb() ath9k_hif_usb_rx_stream() RX_STAT_INC() <--- htc_handle->drv_priv accessIn order to not add fancy protection for drv_priv we can movehtc_handle->drv_priv initialization at the end of theath9k_htc_probe_device() and add helper macro to makeall *_STAT_* macros NULL safe, since syzbot has reported related NULLderef in that macros [1]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-gpu: fix a missing check to avoid NULL dereference'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset()and it will lead to a NULL dereference by a lately use of it(i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check.[ kraxel: minor codestyle fixup ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()The last case label can write two buffers 'mc_reg_address[j]' and'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZEsince there are no checks for this value in both case labels after thelast 'j++'.Instead of changing '>' to '>=' there, add the bounds check at the startof the second 'case' (the first one already has it).Also, remove redundant last checks for 'j' index bigger than array size.The expression is always false. Moreover, before or after the patch'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and itseems it can be a valid value.Detected using the static analysis tool - Svace.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: of: Fix refcount leak bug in of_get_regulation_constraints()We should call the of_node_put() for the reference returned byof_get_child_by_name() which has increased the refcount.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not allow SET_ID to refer to another tableWhen doing lookups for sets on the same batch by using its ID, a set from adifferent table can be used.Then, when the table is removed, a reference to the set may be kept afterthe set is freed, leading to a potential use-after-free.When looking for sets by ID, use the table that was used for the lookup byname, and only return sets belonging to that same table.This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leakFor some sev ioctl interfaces, input may be passed that is less than orequal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSPfirmware returns. In this case, kmalloc will allocate memory that is thesize of the input rather than the size of the data. Since PSP firmwaredoesn't fully overwrite the buffer, the sev ioctl interfaces with theissue may return uninitialized slab memory.Currently, all of the ioctl interfaces in the ccp driver are safe, butto prevent future problems, change all ioctl interfaces that allocatememory with kmalloc to use kzalloc and memset the data buffer to zeroin sev_ioctl_do_platform_status.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0Don't BUG/WARN on interrupt injection due to GIF being cleared,since it's trivial for userspace to force the situation viaKVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correctfor KVM internally generated injections). kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: inject_pending_event+0x2f7/0x4c0 [kvm] kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm] kvm_vcpu_ioctl+0x26d/0x650 [kvm] __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: bcd2000: Fix a UAF bug on the error path of probingWhen the driver fails in snd_card_register() at probe time, it will freethe 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug.The following log can reveal it:[ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000][ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0[ 50.729530] Call Trace:[ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]Fix this by adding usb_kill_urb() before usb_free_urb().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix crash on isr after kexec()If the system is rebooted via isr(), the IRQ handler mightbe triggered before the domain is initialized. Resulting onan invalid memory access error.Fix:[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070[ 0.501166] Call trace:[ 0.501174] report_iommu_fault+0x28/0xfc[ 0.501180] mtk_iommu_isr+0x10c/0x1c0[ joro: Fixed spelling in commit message ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()If vp alloc failed in qlcnic_sriov_init(), all previously allocated vpneeds to be freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()If device_register() fails in cxl_pci_afu|adapter(), the deviceis not added, device_unregister() can not be called in the errorpath, otherwise it will cause a null-ptr-deref because of removingnot added device.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: of: Fix refcount leak bug in of_get_ddr_timings()We should add the of_node_put() when breaking out offor_each_child_of_node() as it will automatically increaseand decrease the refcount.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: make sure skb->len != 0 when redirecting to a tunneling devicesyzkaller managed to trigger another case where skb->len == 0when we enter __dev_queue_xmit:WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6The reproducer doesn't really reproduce outside of syzkallerenvironment, so I'm taking a guess here. It looks like wedo generate correct ETH_HLEN-sized packet, but we redirectthe packet to the tunneling device. Before we do so, we__skb_pull l2 header and arrive again at skb->len == 0.Doesn't seem like we can do anything better than havingan explicit check after __skb_pull?
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/gntdev: Prevent leaking grantsPrior to this commit, if a grant mapping operation failed partially,some of the entries in the map_ops array would be invalid, whereas allof the entries in the kmap_ops array would be valid. This in turn wouldcause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count; i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } } } ... atomic_add(alloced, &map->live_grants);Assume that use_ptemod is true (i.e., the domain mapping the grantedpages is a paravirtualized domain). In the code excerpt above, note thatthe "alloced" variable is only incremented when both kmap_ops[i].statusand map_ops[i].status are set to GNTST_okay (i.e., both mappingoperations are successful). However, as also noted above, there arecases where a grant mapping operation fails partially, breaking theassumption of the code excerpt above.The aforementioned causes map->live_grants to be incorrectly set. Insome cases, all of the map_ops mappings fail, but all of the kmap_opsmappings succeed, meaning that live_grants may remain zero. This in turnmakes it impossible to unmap the successfully grant-mapped pages pointedto by kmap_ops, because unmap_grant_pages has the following snippet ofcode at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */In other cases where only some of the map_ops mappings fail but allkmap_ops mappings succeed, live_grants is made positive, but when theuser requests unmapping the grant-mapped pages, __unmap_grant_pages_donewill then make map->live_grants negative, because the latter functiondoes not check if all of the pages that were requested to be unmappedwere actually unmapped, and the same function unconditionally subtracts"data->count" (i.e., a value that can be greater than map->live_grants)from map->live_grants. The side effects of a negative live_grants valuehave not been studied.The net effect of all of this is that grant references are leaked in oneof the above conditions. In Qubes OS v4.1 (which uses Xen's grantmechanism extensively for X11 GUI isolation), this issue manifestsitself with warning messages like the following to be printed out by theLinux kernel in the VM that had granted pages (that contain X11 GUIwindow data) to dom0: "g.e. 0x1234 still pending", especially after theuser rapidly resizes GUI VM windows (causing some grant-mappingoperations to partially or completely fail, due to the fact that the VMunshares some of the pages as part of the window resizing, making thepages impossible to grant-map from dom0).The fix for this issue involves counting all successful map_ops andkmap_ops mappings separately, and then adding the sum to live_grants.During unmapping, only the number of successfully unmapped grants issubtracted from live_grants. The code is also modified to check fornegative live_grants values after the subtraction and warn the user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_waitkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.syzbot reported:BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfreewrite to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: Fix check for probe enabled in kill_kprobe()In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to becalled always fails. This is because before that we set theKPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is alwaysfalse.The disarm_kprobe_ftrace() call introduced by commit: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")to fix the NULL pointer reference problem. When the probe is enabled, ifwe do not disarm it, this problem still exists.Fix it by putting the probe enabled check before setting theKPROBE_FLAG_GONE flag.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost/vsock: Use kvmalloc/kvfree for larger packets.When copying a large file over sftp over vsock, data size is usually 32kB,and kmalloc seems to fail to try to allocate 32 32kB regions. vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [] dump_stack+0x97/0xdb [] warn_alloc_failed+0x10f/0x138 [] ? __alloc_pages_direct_compact+0x38/0xc8 [] __alloc_pages_nodemask+0x84c/0x90d [] alloc_kmem_pages+0x17/0x19 [] kmalloc_order_trace+0x2b/0xdb [] __kmalloc+0x177/0x1f7 [] ? copy_from_iter+0x8d/0x31d [] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock] [] vhost_worker+0xf7/0x157 [vhost] [] kthread+0xfd/0x105 [] ? vhost_dev_set_owner+0x22e/0x22e [vhost] [] ? flush_kthread_worker+0xf3/0xf3 [] ret_from_fork+0x4e/0x80 [] ? flush_kthread_worker+0xf3/0xf3Work around by doing kvmalloc instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()Wei Chen reports a kernel bug as blew:general protection fault, probably for non-canonical addressKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]...Call Trace:__i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458vfs_ioctl fs/ioctl.c:51 [inline]__do_sys_ioctl fs/ioctl.c:870 [inline]__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fd834a8bdedIn az6027_i2c_xfer(), if msg[i].addr is 0x99,a null-ptr-deref will caused when accessing msg[i].buf.For msg[i].len is 0 and msg[i].buf is null.Fix this by checking msg[i].len in az6027_i2c_xfer().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PNP: fix name memory leak in pnp_alloc_dev()After commit 1fa5ae857bb1 ("driver core: get rid of struct device'sbus_id string array"), the name of device is allocated dynamically,move dev_set_name() after pnp_add_id() to avoid memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pnode: terminate at peers of sourceThe propagate_mnt() function handles mount propagation when creatingmounts and propagates the source mount tree @source_mnt to allapplicable nodes of the destination propagation mount tree headed by@dest_mnt.Unfortunately it contains a bug where it fails to terminate at peers of@source_mnt when looking up copies of the source mount that becomemasters for copies of the source mount tree mounted on top of slaves inthe destination propagation tree causing a NULL dereference.Once the mechanics of the bug are understood it's easy to trigger.Because of unprivileged user namespaces it is available to unprivilegedusers.While fixing this bug we've gotten confused multiple times due tounclear terminology or missing concepts. So let's start this with someclarifications:* The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group.* A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share.* The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list.* The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group.* Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked.* Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from.* A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups.* A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group.* A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group pr---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pagesThe h->*_huge_pages counters are protected by the hugetlb_lock, butalloc_huge_page has a corner case where it can decrement the counteroutside of the lock.This could lead to a corrupted value of h->resv_huge_pages, which we haveobserved on our systems.Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid apotential race.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failureadapter->dcb would get silently freed inside qlcnic_dcb_enable() incase qlcnic_dcb_attach() would return an error, which always happensunder OOM conditions. This would lead to use-after-free because bothof the existing callers invoke qlcnic_dcb_get_info() on the obtainedpointer, which is potentially freed at that point.Propagate errors from qlcnic_dcb_enable(), and instead free the dcbpointer at callsite using qlcnic_dcb_free(). This also removes the nowunused qlcnic_clear_dcb_ops() helper, which was a simple wrapper aroundkfree() also causing memory leaks for partially initialized dcb.Found by Linux Verification Center (linuxtesting.org) with the SVACEstatic analysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_psockkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.We do the same for kcm->rx_wait in the following patch.syzbot reported:BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcmwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff88812971ce00 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a rangeIf we get -ENOMEM while dropping file extent items in a given range, atbtrfs_drop_extents(), due to failure to allocate memory when attempting toincrement the reference count for an extent or drop the reference count,we handle it with a BUG_ON(). This is excessive, instead we can simplyabort the transaction and return the error to the caller. In fact mostcallers of btrfs_drop_extents(), directly or indirectly, already abortthe transaction if btrfs_drop_extents() returns any error.Also, we already have error paths at btrfs_drop_extents() that may return-ENOMEM and in those cases we abort the transaction, like for exampleanything that changes the b+tree may return -ENOMEM due to a failure toallocate a new extent buffer when COWing an existing extent buffer, suchas a call to btrfs_duplicate_item() for example.So replace the BUG_ON() calls with proper logic to abort the transactionand return the error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix memory leak in lbs_init_adapter()When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is notreleased. Add free memory to processing error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: Replace snprintf with scnprintfCurrent code produces a warning as shown below when total charactersin the constituent block device names plus the slashes exceeds 200.snprintf() returns the number of characters generated from the giveninput, which could cause the expression "200 - len" to wrap aroundto a large positive number. Fix this by using scnprintf() instead,which returns the actual number of characters written into the buffer.[ 1513.267938] ------------[ cut here ]------------[ 1513.267943] WARNING: CPU: 15 PID: 37247 at /lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510[ 1513.267944] Modules linked in: [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510<-snip->[ 1513.267982] Call Trace:[ 1513.267986] snprintf+0x45/0x70[ 1513.267990] ? disk_name+0x71/0xa0[ 1513.267993] dump_zones+0x114/0x240 [raid0][ 1513.267996] ? _cond_resched+0x19/0x40[ 1513.267998] raid0_run+0x19e/0x270 [raid0][ 1513.268000] md_run+0x5e0/0xc50[ 1513.268003] ? security_capable+0x3f/0x60[ 1513.268005] do_md_run+0x19/0x110[ 1513.268006] md_ioctl+0x195e/0x1f90[ 1513.268007] blkdev_ioctl+0x91f/0x9f0[ 1513.268010] block_ioctl+0x3d/0x50[ 1513.268012] do_vfs_ioctl+0xa9/0x640[ 1513.268014] ? __fput+0x162/0x260[ 1513.268016] ksys_ioctl+0x75/0x80[ 1513.268017] __x64_sys_ioctl+0x1a/0x20[ 1513.268019] do_syscall_64+0x5e/0x200[ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix double release compute pasidIf kfd_process_device_init_vm returns failure after vm is converted tocompute vm and vm->pasid set to compute pasid, KFD will not takepdd->drm_file reference. As a result, drm close file handler maybecalled to release the compute pasid before KFD process destroy worker torelease the same pasid and set vm->pasid to zero, this generates belowWARNING backtrace and NULL pointer access.Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last stepof kfd_process_device_init_vm, to ensure vm pasid is the original pasidif acquiring vm failed or is the compute pasid with pdd->drm_filereference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: core: fix possible resource leak in init_mtd()I got the error report while inject fault in init_mtd():sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'Call Trace: dump_stack_lvl+0x67/0x83 sysfs_warn_dup+0x60/0x70 sysfs_create_dir_ns+0x109/0x120 kobject_add_internal+0xce/0x2f0 kobject_add+0x98/0x110 device_add+0x179/0xc00 device_create_groups_vargs+0xf4/0x100 device_create+0x7b/0xb0 bdi_register_va.part.13+0x58/0x2d0 bdi_register+0x9b/0xb0 init_mtd+0x62/0x171 [mtd] do_one_initcall+0x6c/0x3c0 do_init_module+0x58/0x222 load_module+0x268e/0x27d0 __do_sys_finit_module+0xd5/0x140 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory.Error registering mtd class or bdi: -17If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,as a result, we can't load the mtd module again, to fix this by callingbdi_unregister(mtd_bdi) after out_procfs label.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix refcount leak in cxl_calc_capp_routingof_get_next_parent() returns a node pointer with refcount incremented,we should use of_node_put() on it when not need anymore.This function only calls of_node_put() in normal path,missing it in the error path.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: serial: jsm: fix some leaks in probeThis error path needs to unwind instead of just returning directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skbin case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.Compile tested only.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: cavium - prevent integer overflow loading firmwareThe "code_length" value comes from the firmware file. If your firmwareis untrusted realistically there is probably very little you can do toprotect yourself. Still we try to limit the damage as much as possible.Also Smatch marks any data read from the filesystem as untrusted andprints warnings if it not capped correctly.The "ntohl(ucode->code_length) * 2" multiplication can have aninteger overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value, the memorythat allocated in mmc_alloc_host() will be leaked and it will lead a kernelcrash because of deleting not added device in the remove path.So fix this by checking the return value and calling mmc_free_host() in theerror path, besides, led_classdev_unregister() and pm_runtime_disable() alsoneed be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()If device_register() returns error in tifm_7xx1_switch_media(),name of kobject which is allocated in dev_set_name() called in device_add()is leaked.Never directly free @dev after calling device_register(), evenif it returned an error! Always use put_device() to give up thereference initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix xid leak in cifs_create()If the cifs already shutdown, we should free the xid before return,otherwise, the xid will be leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns: fix possible memory leak in hnae_ae_register()Inject fault while probing module, if device_register() fails,but the refcount of kobject is not decreased to 0, the nameallocated in dev_set_name() is leaked. Fix this by callingput_device(), so that name can be freed in callback functionkobject_cleanup().unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: wmt-sdmmc: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value, the memorythat allocated in mmc_alloc_host() will be leaked and it will lead a kernelcrash because of deleting not added device in the remove path.So fix this by checking the return value and goto error path which will callmmc_free_host(), besides, clk_disable_unprepare() also needs be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: sfb: fix null pointer access issue when sfb_init() failsWhen the default qdisc is sfb, if the qdisc of dev_queue fails to beinited during mqprio_init(), sfb_reset() is invoked to clear resources.In this case, the q->qdisc is NULL, and it will cause gpf issue.The process is as follows:qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->opsThe following is the Call Trace information:general protection fault, probably for non-canonical address0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]RIP: 0010:qdisc_reset+0x2b/0x6f0Call Trace:sfb_reset+0x37/0xd0qdisc_reset+0xed/0x6f0qdisc_destroy+0x82/0x4c0qdisc_put+0x9e/0xb0qdisc_create_dflt+0x2c3/0x4a0mqprio_init+0xa71/0x1760qdisc_create+0x3eb/0x1000tc_modify_qdisc+0x408/0x1720rtnetlink_rcv_msg+0x38e/0xac0netlink_rcv_skb+0x12d/0x3a0netlink_unicast+0x4a2/0x740netlink_sendmsg+0x826/0xcc0sock_sendmsg+0xc5/0x100____sys_sendmsg+0x583/0x690___sys_sendmsg+0xe8/0x160__sys_sendmsg+0xbf/0x160do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f2164122d04
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx88: Fix a null-ptr-deref bug in buffer_prepare()When the driver calls cx88_risc_buffer() to prepare the buffer, thefunction call may fail, resulting in a empty buffer and null-ptr-dereflater in buffer_queue().The following log can reveal it:[ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI[ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007][ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500[ 41.836311] Call Trace:[ 41.836945] __enqueue_in_driver+0x141/0x360[ 41.837262] vb2_start_streaming+0x62/0x4a0[ 41.838216] vb2_core_streamon+0x1da/0x2c0[ 41.838516] __vb2_init_fileio+0x981/0xbc0[ 41.839141] __vb2_perform_fileio+0xbf9/0x1120[ 41.840072] vb2_fop_read+0x20e/0x400[ 41.840346] v4l2_read+0x215/0x290[ 41.840603] vfs_read+0x162/0x4c0Fix this by checking the return value of cx88_risc_buffer()[hverkuil: fix coding style issues]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: mux: reg: check return value after calling platform_get_resource()It will cause null-ptr-deref in resource_size(), if platform_get_resource()returns NULL, move calling resource_size() after devm_ioremap_resource() thatwill check 'res' to avoid null-ptr-deref.And use devm_platform_get_and_ioremap_resource() to simplify code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: Account for tail adjustment during pull operationsExtending the tail can have some unexpected side effects if a program usesa helper like BPF_FUNC_skb_pull_data to read partial content beyond thehead skb headlen when all the skbs in the gso frag_list are linear with nohead_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60Fix this by marking these skbs as GSO_DODGY so segmentation can handlethe tail updates accordingly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dsi: fix memory corruption with too many bridgesAdd the missing sanity check on the bridge counter to avoid corruptingdata beyond the fixed-sized bridge array in case there are ever morethan eight bridges.Patchwork: https://patchwork.freedesktop.org/patch/502668/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdownlpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer canstill occur which in turn tries to access dma apis if lpuart_dma_tx_useflag is true. At this point since dma is torn down, these dma apis canabort. Set lpuart_dma_tx_use and the corresponding rx flaglpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are notaccessed after they are relinquished.Otherwise, when try to kill btattach, kernel may panic. This patch mayfix this issue.root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP[ 90.189806] Modules linked in: moal(O) mlan(O)[ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37[ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT)[ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60[ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c[ 90.225237] sp : ffff800013f0bac0[ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800[ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00[ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000[ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000[ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040[ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090[ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804[ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480[ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800[ 90.299876] Call trace:[ 90.302321] fsl_edma3_disable_request+0x8/0x60[ 90.306851] lpuart_flush_buffer+0x40/0x160[ 90.311037] uart_flush_buffer+0x88/0x120[ 90.315050] tty_driver_flush_buffer+0x20/0x30[ 90.319496] hci_uart_flush+0x44/0x90[ 90.323162] +0x34/0x12c[ 90.327253] tty_ldisc_close+0x38/0x70[ 90.331005] tty_ldisc_release+0xa8/0x190[ 90.335018] tty_release_struct+0x24/0x8c[ 90.339022] tty_release+0x3ec/0x4c0[ 90.342593] __fput+0x70/0x234[ 90.345652] ____fput+0x14/0x20[ 90.348790] task_work_run+0x84/0x17c[ 90.352455] do_exit+0x310/0x96c[ 90.355688] do_group_exit+0x3c/0xa0[ 90.359259] __arm64_sys_exit_group+0x1c/0x20[ 90.363609] invoke_syscall+0x48/0x114[ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc[ 90.372068] do_el0_svc+0x2c/0x94[ 90.375379] el0_svc+0x28/0x80[ 90.378438] el0t_64_sync_handler+0xa8/0x130[ 90.382711] el0t_64_sync+0x1a0/0x1a4[ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041)[ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]---[ 90.397073] note: btattach[503] exited with preempt_count 1[ 90.402636] Fixing recursive fault but reboot is needed!
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix an Oops in nfs_d_automount()When mounting from a NFSv4 referral, path->dentry can end up being anegative dentry, so derive the struct nfs_server from the dentryitself instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: ismt: Fix an out-of-bounds bug in ismt_access()When the driver does not check the data from the user, the variable'data->block[0]' may be very large to cause an out-of-bounds bug.The following log can reveal it:[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20[ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE[ 33.996475] ==================================================================[ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b[ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485[ 33.999450] Call Trace:[ 34.001849] memcpy+0x20/0x60[ 34.002077] ismt_access.cold+0x374/0x214b[ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0[ 34.004007] i2c_smbus_xfer+0x10a/0x390[ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710[ 34.005196] i2cdev_ioctl+0x5ec/0x74cFix this bug by checking the size of 'data->block[0]' first.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:integrity: Fix memory leakage in keyring allocation error pathKey restriction is allocated in integrity_init_keyring(). However, ifkeyring allocation failed, it is not freed, causing memory leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix memory leak in tcindex_set_parmsSyzkaller reports a memory leak as follows:====================================BUG: memory leakunreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] kmalloc_array include/linux/slab.h:627 [inline] [] kcalloc include/linux/slab.h:659 [inline] [] tcf_exts_init include/net/pkt_cls.h:250 [inline] [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [] sock_sendmsg_nosec net/socket.c:714 [inline] [] sock_sendmsg+0x56/0x80 net/socket.c:734 [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [] __do_sys_sendmmsg net/socket.c:2651 [inline] [] __se_sys_sendmmsg net/socket.c:2648 [inline] [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd====================================Kernel uses tcindex_change() to change an existingfilter properties.Yet the problem is that, during the process of changing,if `old_r` is retrieved from `p->perfect`, thenkernel uses tcindex_alloc_perfect_hash() to newlyallocate filter results, uses tcindex_filter_result_init()to clear the old filter result, without destroyingits tcf_exts structure, which triggers the above memory leak.To be more specific, there are only two source for the `old_r`,according to the tcindex_lookup(). `old_r` is retrieved from`p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel usestcindex_alloc_perfect_hash() to newly allocate thefilter results. Then `r` is assigned with `cp->perfect + handle`,which is newly allocated. So condition `old_r && old_r != r` istrue in this situation, and kernel uses tcindex_filter_result_init()to clear the old filter result, without destroyingits tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULLaccording to the tcindex_lookup(). Considering that `cp->h`is directly copied from `p->h` and `p->perfect` is NULL,`r` is assigned with `tcindex_lookup(cp, handle)`, whose valueshould be the same as `old_r`, so condition `old_r && old_r != r`is false in this situation, kernel ignores usingtcindex_filter_result_init() to clear the old filter result.So only when `old_r` is retrieved from `p->perfect` does kernel usetcindex_filter_result_init() to clear the old filter result, whichtriggers the above memory leak.Considering that there already exists a tc_filter_wq workqueueto destroy the old tcindex_d---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: iomap: fix memory corruption when recording errors during writebackEvery now and then I see this crash on arm64:Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8Buffer I/O error on dev dm-0, logical block 8733687, async page readMem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation faultData abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000[00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000Internal error: Oops: 96000006 [#1] PREEMPT SMPBuffer I/O error on dev dm-0, logical block 8733688, async page readDumping ftrace buffer:Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty)XFS (dm-0): log I/O error -5Modules linked in: dm_thin_pool dm_persistent_dataXFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prisonXFS (dm-0): Please unmount the filesystem and rectify the problem(s)XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECTpotentially unexpected fatal signal 6. nf_reject_ipv6potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tablesHardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tablespc : 000003fd6d7df200 x_tableslr : 000003fd6d7df1ec overlay nfsv4CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021Workqueue: writeback wb_workfnsp : 000003ffd9522fd0 (flush-253:0)pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--)pc : errseq_set+0x1c/0x100x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000x23: 00000000ffffffff x22: 0000000000000005lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006sp : fffffe000f80f760x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b]x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffeex5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000CPU: ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Protect against send buffer overflow in NFSv2 READSince before the git era, NFSD has conserved the number of pagesheld by each nfsd thread by combining the RPC receive and sendbuffers into a single array of pages. This works because there areno cases where an operation needs a large RPC Call message and alarge RPC Reply at the same time.Once an RPC Call has been received, svc_process() updatessvc_rqst::rq_res to describe the part of rq_pages that can beused for constructing the Reply. This means that the send buffer(rq_res) shrinks when the received RPC record containing the RPCCall is large.A client can force this shrinkage on TCP by sending a correctly-formed RPC Call header contained in an RPC record that isexcessively large. The full maximum payload size cannot beconstructed in that case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid crash when inline data creation follows DIO writeWhen inode is created and written to using direct IO, there is nothingto clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode getstruncated later to say 1 byte and written using normal write, we willtry to store the data as inline data. This confuses the code laterbecause the inode now has both normal block and inline data allocatedand the confusion manifests for example as:kernel BUG at fs/ext4/inode.c:2721!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014RIP: 0010:ext4_writepages+0x363d/0x3660RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680bR10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0Call Trace: do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doingdirect IO write to a file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Validate the box size for the snooped cursorInvalid userspace dma surface copies could potentially overflowthe memcpy from the surface to the snooped image leading to crashes.To fix it the dimensions of the copybox have to be validatedagainst the expected size of the snooped cursor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: fix NULL-pointer dereferencesThere are several places where we can crash the kernel by requestinglines, unbinding the GPIO device, then calling any of the system callsrelevant to the GPIO character device's annonymous file descriptors:ioctl(), read(), poll().While I observed it with the GPIO simulator, it will also happen for anyof the GPIO devices that can be hot-unplugged - for instance any HID GPIOexpander (e.g. CP2112).This affects both v1 and v2 uAPI.This fixes it partially by checking if gdev->chip is not NULL but itdoesn't entirely remedy the situation as we still have a race conditionin which another thread can remove the device after the check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix resolving backrefs for inline extent followed by preallocIf a file consists of an inline extent followed by a regular or preallocextent, then a legitimate attempt to resolve a logical address in thenon-inline region will result in add_all_parents reading the invalidoffset field of the inline extent. If the inline extent item is placedin the leaf eb s.t. it is the first item, attempting to access theoffset field will not only be meaningless, it will go past the end ofthe eb and cause this panic: [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8 [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199 [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110 [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202 [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000 [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001 [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918 [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000 [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0 [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [17.676034] PKRU: 55555554 [17.677004] Call Trace: [17.677877] add_all_parents+0x276/0x480 [17.679325] find_parent_nodes+0xfae/0x1590 [17.680771] btrfs_find_all_leafs+0x5e/0xa0 [17.682217] iterate_extent_inodes+0xce/0x260 [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0 [17.687404] iterate_inodes_from_logical+0xa1/0xd0 [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190 [17.692946] btrfs_ioctl+0x104a/0x2f60 [17.694384] ? selinux_file_ioctl+0x182/0x220 [17.695995] ? __x64_sys_ioctl+0x84/0xc0 [17.697394] __x64_sys_ioctl+0x84/0xc0 [17.698697] do_syscall_64+0x33/0x40 [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae [17.701753] RIP: 0033:0x7f64e72761b7 [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7 [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003 [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60 [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001 [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0 [17.724839] Modules linked in:Fix the bug by detecting the inline extent item in add_all_parents andskipping to the next extent item.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()Fix a NULL pointer crash that occurs when we are freeing the socket at thesame time we access it via sysfs.The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops.Above we do a get on the "struct sock", but we needed a get on the "structsocket". Originally, we just held the frwd_lock the entire time but incommit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock whilecalling getpeername()") we switched to refcount based because the networklayer changed and started taking a mutex in that path, so we could nolonger hold the frwd_lock.Instead of trying to maintain multiple refcounts, this just has us use amutex for accessing the socket in the interface code paths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()If device_register() fails in cxl_register_afu|adapter(), the deviceis not added, device_unregister() can not be called in the error path,otherwise it will cause a null-ptr-deref because of removing not addeddevice.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crashWhen CPU 0 is offline and intel_powerclamp is used to injectidle, it generates kernel BUG:BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687caller is debug_smp_processor_id+0x17/0x20CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57Call Trace:dump_stack_lvl+0x49/0x63dump_stack+0x10/0x16check_preemption_disabled+0xdd/0xe0debug_smp_processor_id+0x17/0x20powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]......Here CPU 0 is the control CPU by default and changed to the current CPU,if CPU 0 offlined. This check has to be performed under cpus_read_lock(),hence the above warning.Use get_cpu() instead of smp_processor_id() to avoid this BUG.[ rjw: Subject edits ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for dcoda_iram_allocAs the coda_iram_alloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas: avoid scheduling in rtas_os_term()It's unsafe to use rtas_busy_delay() to handle a busy status fromthe ibm,os-term RTAS function in rtas_os_term():Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000bBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 2, expected: 0CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9Call Trace:[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200Use rtas_busy_delay_time() instead, which signals without side effectswhether to attempt the ibm,os-term RTAS call again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix pci device refcount leak in ppr_notifier()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it before returning from ppr_notifier()to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for kmallocAs the kmalloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:lib/fonts: fix undefined behavior in bit shift for get_default_fontShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20left shift of 1 by 31 places cannot be represented in type 'int' dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix invalid derefence of sb_lvbptrI experience issues when putting a lkbsb on the stack and have sb_lvbptrfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crashwith the following kernel message, the dangled pointer is here0xdeadbeef as example:[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef[ 102.749320] #PF: supervisor read access in kernel mode[ 102.749323] #PF: error_code(0x0000) - not-present page[ 102.749325] PGD 0 P4D 0[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 102.749379] PKRU: 55555554[ 102.749381] Call Trace:[ 102.749382] [ 102.749383] ? send_args+0xb2/0xd0[ 102.749389] send_common+0xb7/0xd0[ 102.749395] _unlock_lock+0x2c/0x90[ 102.749400] unlock_lock.isra.56+0x62/0xa0[ 102.749405] dlm_unlock+0x21e/0x330[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture][ 102.749419] ? preempt_count_sub+0xba/0x100[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture][ 102.786186] kthread+0x10a/0x130[ 102.786581] ? kthread_complete_and_exit+0x20/0x20[ 102.787156] ret_from_fork+0x22/0x30[ 102.787588] [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw[ 102.792536] CR2: 00000000deadbeef[ 102.792930] ---[ end trace 0000000000000000 ]---This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflagsis set when copying the lvbptr array instead of if it's just null whichfixes for me the issue.I think this patch can fix other dlm users as well, depending how theyhandle the init, freeing memory handling of sb_lvbptr and don't setDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be ahidden issue all the time. However with checking on DLM_LKF_VALBLK theuser always need to provide a sb_lvbptr non-null value. There might bemore intelligent handling between per ls lvblen, DLM_LKF_VALBLK andnon-null to report the user the way how DLM API is used is wrong but canbe added for later, this will only fix the current behaviour.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix size validation for non-exclusive domains (v4)Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for therequested memory exists, else we get a kernel oops when dereferencing "man".v2: Make the patch standalone, i.e. not dependent on local patches.v3: Preserve old behaviour and just check that the manager pointer is not NULL.v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,sas_rphy_free() needs be called to free the resource allocated insas_end_device_alloc(). Otherwise a kernel crash will happen:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : device_del+0x54/0x3d0lr : device_del+0x37c/0x3d0Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas]Because transport_add_device() is not called when sas_rphy_add() fails, thedevice is not added. When sas_rphy_remove() is subsequently called toremove the device in the remove() path, a NULL pointer dereference happens.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Use last transaction's pmd->root when commit failedRecently we found a softlock up problem in dm thin pool btree lookupcode due to corrupted metadata: Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x9c/0xd3 panic+0x35d/0x6b9 watchdog_timer_fn.cold+0x16/0x25 __run_hrtimer+0xa2/0x2d0 RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio] __bufio_new+0x11f/0x4f0 [dm_bufio] new_read+0xa3/0x1e0 [dm_bufio] dm_bm_read_lock+0x33/0xd0 [dm_persistent_data] ro_step+0x63/0x100 [dm_persistent_data] btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data] dm_btree_lookup+0x16f/0x210 [dm_persistent_data] dm_thin_find_block+0x12c/0x210 [dm_thin_pool] __process_bio_read_only+0xc5/0x400 [dm_thin_pool] process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool] process_one_work+0x3c5/0x730Following process may generate a broken btree mixed with fresh andstale btree nodes, which could get dm thin trapped in an infinite loopwhile looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. process_bio_read_only dm_thin_find_block __find_block dm_btree_lookup(pmd->root)The pmd->root points to a broken btree, Y may contain stale nodepointing to any block, for example X, which gets dm thin trapped intoa dead loop while looking up Z.Fix this by setting pmd->root in __open_metadata(), so that dm thinwill use the last transaction's pmd->root if commit failed.Fetch a reproducer in [Link].Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix repeated calls to sock_put() when msg has more_dataIn tcp_bpf_send_verdict() redirection, the eval variable is assigned to__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,sock_put() will be called multiple times.We should reset the eval variable to __SK_NONE every time more_datastarts.This causes:IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110Modules linked in:CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014Call Trace: __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' willnot be freed through rpi_firmware_delete(), fix this leak by callingkfree() in the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()xhci_alloc_stream_info() allocates stream context array for stream_info->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,stream_info->stream_ctx_array is not released, which will lead to amemory leak.We can fix it by releasing the stream_info->stream_ctx_array withxhci_free_stream_ctx() on the error path to avoid the potential memoryleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:r6040: Fix kmemleak in probe and removeThere is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ...The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problemThe root cause is traced to the phy_device is not disconnected whenremoves one r6040 device in r6040_remove_one() or on error handling pathafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernetdevice is connected to the first PHY device of mii_bus, in order tonotify the connected driver when the link status changes, which is thedefault behavior of the PHY infrastructure to handle everything.Therefore the phy_device should be disconnected when removes one r6040device or on error handling path.Fix it by adding phy_disconnect() when removes one r6040 device or onerror handling path after r6040_mii probed successfully.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadataFollowing concurrent processes: P1(drop cache) P2(kworker)drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block v down_read(&pmd->root_lock) --> ABBA deadlock, which triggers hung task:[ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.[ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2[ 76.978534] Workqueue: dm-thin do_worker[ 76.978552] Call Trace:[ 76.978564] __schedule+0x6ba/0x10f0[ 76.978582] schedule+0x9d/0x1e0[ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0[ 76.978600] down_write+0xec/0x110[ 76.978607] unregister_shrinker+0x2c/0xf0[ 76.978616] dm_bufio_client_destroy+0x116/0x3d0[ 76.978625] dm_block_manager_destroy+0x19/0x40[ 76.978629] __destroy_persistent_data_objects+0x5e/0x70[ 76.978636] dm_pool_abort_metadata+0x8e/0x100[ 76.978643] metadata_operation_failed+0x86/0x110[ 76.978649] commit+0x6a/0x230[ 76.978655] do_worker+0xc6e/0xd90[ 76.978702] process_one_work+0x269/0x630[ 76.978714] worker_thread+0x266/0x630[ 76.978730] kthread+0x151/0x1b0[ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.[ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459[ 76.982128] Call Trace:[ 76.982139] __schedule+0x6ba/0x10f0[ 76.982155] schedule+0x9d/0x1e0[ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910[ 76.982173] down_read+0x84/0x170[ 76.982177] dm_thin_find_block+0x4c/0xd0[ 76.982183] thin_map+0x201/0x3d0[ 76.982188] __map_bio+0x5b/0x350[ 76.982195] dm_submit_bio+0x2b6/0x930[ 76.982202] __submit_bio+0x123/0x2d0[ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0[ 76.982222] submit_bio_noacct+0x389/0x770[ 76.982227] submit_bio+0x50/0xc0[ 76.982232] submit_bh_wbc+0x15e/0x230[ 76.982238] submit_bh+0x14/0x20[ 76.982241] ext4_read_bh_nowait+0xc5/0x130[ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60[ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0[ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0[ 76.982263] ext4_discard_preallocations+0x45d/0x830[ 76.982274] ext4_clear_inode+0x48/0xf0[ 76.982280] ext4_evict_inode+0xcf/0xc70[ 76.982285] evict+0x119/0x2b0[ 76.982290] dispose_list+0x43/0xa0[ 76.982294] prune_icache_sb+0x64/0x90[ 76.982298] super_cache_scan+0x155/0x210[ 76.982303] do_shrink_slab+0x19e/0x4e0[ 76.982310] shrink_slab+0x2bd/0x450[ 76.982317] drop_slab+0xcc/0x1a0[ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0[ 76.982327] proc_sys_call_handler+0x1bc/0x300[ 76.982331] proc_sys_write+0x17/0x20[ 76.982334] vfs_write+0x3d3/0x570[ 76.982342] ksys_write+0x73/0x160[ 76.982347] __x64_sys_write+0x1e/0x30[ 76.982352] do_syscall_64+0x35/0x80[ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcdFunct---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()This patch fixes a shift-out-of-bounds in brcmfmac that occurs inBIT(chiprev) when a 'chiprev' provided by the device is too large.It should also not be equal to or greater than BITS_PER_TYPE(u32)as we do bitwise AND with a u32 variable and BIT(chiprev). The patchadds a check that makes the function return NULL if that is the case.Note that the NULL case is later handled by the bus-specific caller,brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.Found by a modified version of syzkaller.UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.cshift exponent 151055786 is too large for 64-bit type 'long unsigned int'CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? pr---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/netiucv: Fix return type of netiucv_tx()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netiucv_tx, ^~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.Additionally, while in the area, remove a comment block that is nolonger relevant.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netsec: fix error handling in netsec_register_mdio()If phy_device_register() fails, phy_device_free() need be called toput refcount, so memory of phy device and device name can be freedin callback function.If get_phy_device() fails, mdiobus_unregister() need be called,or it will cause warning in mdiobus_free() and kobject is leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: core: Fix kernel panic when remove non-standard SDIO cardSDIO tuple is only allocated for standard SDIO card, especially it causesmemory corruption issues when the non-standard SDIO card has removed, whichis because the card device's reference counter does not increase for it atsdio_init_func(), but all SDIO card device reference counter gets decreasedat sdio_release_func().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: associate skb with a device at txSyzkaller triggered flow dissector warning with the following:r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0[ 9.485929] skb_get_poff+0x53/0xa0[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20[ 9.485944] ? ppp_send_frame+0xc2/0x5b0[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0[ 9.485968] ? ppp_xmit_process+0x5b/0xb0[ 9.485974] ? ppp_write+0x12a/0x190[ 9.485981] ? do_iter_write+0x18e/0x2d0[ 9.485987] ? __import_iovec+0x30/0x130[ 9.485997] ? do_pwritev+0x1b6/0x240[ 9.486016] ? trace_hardirqs_on+0x47/0x50[ 9.486023] ? __x64_sys_pwritev+0x24/0x30[ 9.486026] ? do_syscall_64+0x3d/0x80[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcdFlow dissector tries to find skb net namespace either via deviceor via socket. Neigher is set in ppp_send_frame, so let's manuallyuse ppp->dev.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ipw2200: fix memory leak in ipw_wdev_init()In the error path of ipw_wdev_init(), exception value is returned, andthe memory applied for in the function is not released. Also the memoryis not released in ipw_pci_probe(). As a result, memory leakage occurs.So memory release needs to be added to the error path of ipw_wdev_init().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix "kernel NULL pointer dereference" errorWhen rxe_queue_init in the function rxe_qp_init_req fails,both qp->req.task.func and qp->req.task.arg are not initialized.Because of creation of qp fails, the function rxe_create_qp willcall rxe_qp_do_cleanup to handle allocated resource.Before calling __rxe_do_task, both qp->req.task.func andqp->req.task.arg should be checked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], forcommit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication inrds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a sectionprotected by lock_sock() without realizing that rds_send_xmit() might calllock_sock().We don't need to protect cancel_delayed_work_sync() using lock_sock(), foreven if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete,retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UPbit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix invalid address access when enabling SCAN log levelThe variable i is changed when setting random MAC address and causesinvalid address access when printing the value of pi->reqs[i]->reqid.We replace reqs index with ri to fix the issue.[ 136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000[ 136.737365] Mem abort info:[ 136.740172] ESR = 0x96000004[ 136.743359] Exception class = DABT (current EL), IL = 32 bits[ 136.749294] SET = 0, FnV = 0[ 136.752481] EA = 0, S1PTW = 0[ 136.755635] Data abort info:[ 136.758514] ISV = 0, ISS = 0x00000004[ 136.762487] CM = 0, WnR = 0[ 136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577[ 136.772265] [0000000000000000] pgd=0000000000000000[ 136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP[ 136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O)[ 136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb)[ 136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G O 4.19.42-00001-g531a5f5 #1[ 136.805532] Hardware name: Freescale i.MX8MQ EVK (DT)[ 136.810584] pstate: 60400005 (nZCv daif +PAN -UAO)[ 136.815429] pc : brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac][ 136.821811] lr : brcmf_pno_config_sched_scans+0x67c/0xa80 [brcmfmac][ 136.828162] sp : ffff00000e9a3880[ 136.831475] x29: ffff00000e9a3890 x28: ffff800020543400[ 136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0[ 136.842098] x25: ffff80002054345c x24: ffff800088d22400[ 136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8[ 136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400[ 136.858032] x19: ffff00000e9a3946 x18: 0000000000000000[ 136.863343] x17: 0000000000000000 x16: 0000000000000000[ 136.868655] x15: ffff0000093f3b37 x14: 0000000000000050[ 136.873966] x13: 0000000000003135 x12: 0000000000000000[ 136.879277] x11: 0000000000000000 x10: ffff000009a61888[ 136.884589] x9 : 000000000000000f x8 : 0000000000000008[ 136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d[ 136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942[ 136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8[ 136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000[ 136.911146] Call trace:[ 136.913623] brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac][ 136.919658] brcmf_pno_start_sched_scan+0xa4/0x118 [brcmfmac][ 136.925430] brcmf_cfg80211_sched_scan_start+0x80/0xe0 [brcmfmac][ 136.931636] nl80211_start_sched_scan+0x140/0x308 [cfg80211][ 136.937298] genl_rcv_msg+0x358/0x3f4[ 136.940960] netlink_rcv_skb+0xb4/0x118[ 136.944795] genl_rcv+0x34/0x48[ 136.947935] netlink_unicast+0x264/0x300[ 136.951856] netlink_sendmsg+0x2e4/0x33c[ 136.955781] __sys_sendto+0x120/0x19c
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: Fix use-after-free on ar5523_cmd() timed outsyzkaller reported use-after-free with the stack trace like below [1]:[ 38.960489][ C3] ==================================================================[ 38.963216][ C3] BUG: KASAN: use-after-free in ar5523_cmd_tx_cb+0x220/0x240[ 38.964950][ C3] Read of size 8 at addr ffff888048e03450 by task swapper/3/0[ 38.966363][ C3][ 38.967053][ C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.0.0-09039-ga6afa4199d3d-dirty #18[ 38.968464][ C3] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014[ 38.969959][ C3] Call Trace:[ 38.970841][ C3] [ 38.971663][ C3] dump_stack_lvl+0xfc/0x174[ 38.972620][ C3] print_report.cold+0x2c3/0x752[ 38.973626][ C3] ? ar5523_cmd_tx_cb+0x220/0x240[ 38.974644][ C3] kasan_report+0xb1/0x1d0[ 38.975720][ C3] ? ar5523_cmd_tx_cb+0x220/0x240[ 38.976831][ C3] ar5523_cmd_tx_cb+0x220/0x240[ 38.978412][ C3] __usb_hcd_giveback_urb+0x353/0x5b0[ 38.979755][ C3] usb_hcd_giveback_urb+0x385/0x430[ 38.981266][ C3] dummy_timer+0x140c/0x34e0[ 38.982925][ C3] ? notifier_call_chain+0xb5/0x1e0[ 38.984761][ C3] ? rcu_read_lock_sched_held+0xb/0x60[ 38.986242][ C3] ? lock_release+0x51c/0x790[ 38.987323][ C3] ? _raw_read_unlock_irqrestore+0x37/0x70[ 38.988483][ C3] ? __wake_up_common_lock+0xde/0x130[ 38.989621][ C3] ? reacquire_held_locks+0x4a0/0x4a0[ 38.990777][ C3] ? lock_acquire+0x472/0x550[ 38.991919][ C3] ? rcu_read_lock_sched_held+0xb/0x60[ 38.993138][ C3] ? lock_acquire+0x472/0x550[ 38.994890][ C3] ? dummy_urb_enqueue+0x860/0x860[ 38.996266][ C3] ? do_raw_spin_unlock+0x16f/0x230[ 38.997670][ C3] ? dummy_urb_enqueue+0x860/0x860[ 38.999116][ C3] call_timer_fn+0x1a0/0x6a0[ 39.000668][ C3] ? add_timer_on+0x4a0/0x4a0[ 39.002137][ C3] ? reacquire_held_locks+0x4a0/0x4a0[ 39.003809][ C3] ? __next_timer_interrupt+0x226/0x2a0[ 39.005509][ C3] __run_timers.part.0+0x69a/0xac0[ 39.007025][ C3] ? dummy_urb_enqueue+0x860/0x860[ 39.008716][ C3] ? call_timer_fn+0x6a0/0x6a0[ 39.010254][ C3] ? cpuacct_percpu_seq_show+0x10/0x10[ 39.011795][ C3] ? kvm_sched_clock_read+0x14/0x40[ 39.013277][ C3] ? sched_clock_cpu+0x69/0x2b0[ 39.014724][ C3] run_timer_softirq+0xb6/0x1d0[ 39.016196][ C3] __do_softirq+0x1d2/0x9be[ 39.017616][ C3] __irq_exit_rcu+0xeb/0x190[ 39.019004][ C3] irq_exit_rcu+0x5/0x20[ 39.020361][ C3] sysvec_apic_timer_interrupt+0x8f/0xb0[ 39.021965][ C3] [ 39.023237][ C3] In ar5523_probe(), ar5523_host_available() calls ar5523_cmd() as below(there are other functions which finally call ar5523_cmd()):ar5523_probe()-> ar5523_host_available() -> ar5523_cmd_read() -> ar5523_cmd()If ar5523_cmd() timed out, then ar5523_host_available() failed andar5523_probe() freed the device structure. So, ar5523_cmd_tx_cb()might touch the freed structure.This patch fixes this issue by canceling in-flight tx cmd if submittedurb timed out.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/lcs: Fix return type of lcs_start_xmit()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8192u: Fix use after free in ieee80211_rx()We cannot dereference the "skb" pointer after callingieee80211_monitor_rx(), because it is a use after free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfsDuring I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, ahard lockup similar to the call trace below may occur.The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timerinterrupts as expected, so change the strength of the spin lock to _irq.Kernel panic - not syncing: Hard LOCKUPCPU: 3 PID: 110402 Comm: cat Kdump: loadedexception RIP: native_queued_spin_lock_slowpath+91[IRQ stack] native_queued_spin_lock_slowpath at ffffffffb814e30b _raw_spin_lock at ffffffffb89a667a lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc] lpfc_cmf_timer at ffffffffc0abbc67 [lpfc] __hrtimer_run_queues at ffffffffb8184250 hrtimer_interrupt at ffffffffb8184ab0 smp_apic_timer_interrupt at ffffffffb8a026ba apic_timer_interrupt at ffffffffb8a01c4f[End of IRQ stack] apic_timer_interrupt at ffffffffb8a01c4f lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc] lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc] full_proxy_read at ffffffffb83e7fc3 vfs_read at ffffffffb833fe71 ksys_read at ffffffffb83402af do_syscall_64 at ffffffffb800430b entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()Running rcutorture with non-zero fqs_duration module parameter in akernel built with CONFIG_PREEMPTION=y results in the following splat:BUG: using __this_cpu_read() in preemptible [00000000]code: rcu_torture_fqs/398caller is __this_cpu_preempt_check+0x13/0x20CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+Call Trace:dump_stack_lvl+0x5b/0x86dump_stack+0x10/0x16check_preemption_disabled+0xe5/0xf0__this_cpu_preempt_check+0x13/0x20rcu_force_quiescent_state.part.0+0x1c/0x170rcu_force_quiescent_state+0x1e/0x30rcu_torture_fqs+0xca/0x160? rcu_torture_boost+0x430/0x430kthread+0x192/0x1d0? kthread_complete_and_exit+0x30/0x30ret_from_fork+0x22/0x30The problem is that rcu_force_quiescent_state() uses __this_cpu_read()in preemptible code instead of the proper raw_cpu_read(). This committherefore changes __this_cpu_read() to raw_cpu_read().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interruptI got a null-ptr-defer error report when I do the following testson the qemu platform:make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,CONFIG_SND_MTS64=mThen making test scripts:cat>test_mod1.sh< snd_mts64_interrupt+0x24/0xa0 [snd_mts64] parport_irq_handler+0x37/0x50 [parport] __handle_irq_event_percpu+0x39/0x190 handle_irq_event_percpu+0xa/0x30 handle_irq_event+0x2f/0x50 handle_edge_irq+0x99/0x1b0 __common_interrupt+0x5d/0x100 common_interrupt+0xa0/0xc0 asm_common_interrupt+0x22/0x40 RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30 parport_claim+0xbd/0x230 [parport] snd_mts64_probe+0x14a/0x465 [snd_mts64] platform_probe+0x3f/0xa0 really_probe+0x129/0x2c0 __driver_probe_device+0x6d/0xc0 driver_probe_device+0x1a/0xa0 __device_attach_driver+0x7a/0xb0 bus_for_each_drv+0x62/0xb0 __device_attach+0xe4/0x180 bus_probe_device+0x82/0xa0 device_add+0x550/0x920 platform_device_add+0x106/0x220 snd_mts64_attach+0x2e/0x80 [snd_mts64] port_check+0x14/0x20 [parport] bus_for_each_dev+0x6e/0xc0 __parport_register_driver+0x7c/0xb0 [parport] snd_mts64_module_init+0x31/0x1000 [snd_mts64] do_one_initcall+0x3c/0x1f0 do_init_module+0x46/0x1c6 load_module+0x1d8d/0x1e10 __do_sys_finit_module+0xa2/0xf0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 1 seconds..The mts wa not initialized during interrupt, we add check formts to fix this bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: st: Fix memory leak in st_of_quadfs_setup()If st_clk_register_quadfs_pll() fails, @lock should be freed before goto@err_exit, otherwise will cause meory leak issue, fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix bug_on in __es_tree_search caused by bad quota inodeWe got a issue as fllows:================================================================== kernel BUG at fs/ext4/extents_status.c:202! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 810 Comm: mount Not tainted 6.1.0-rc1-next-g9631525255e3 #352 RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0 RSP: 0018:ffffc90001227900 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8 RBP: ffff888177512ac8 R08: 47ffffffffffffff R09: 0000000000000001 R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10 R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000 FS: 00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ext4_es_cache_extent+0xe2/0x210 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_getblk+0x82/0x340 ext4_bread+0x14/0x110 ext4_quota_read+0xf0/0x180 v2_read_header+0x24/0x90 v2_check_quota_file+0x2f/0xa0 dquot_load_quota_sb+0x26c/0x760 dquot_load_quota_inode+0xa5/0x190 ext4_enable_quotas+0x14c/0x300 __ext4_fill_super+0x31cc/0x32c0 ext4_fill_super+0x115/0x2d0 get_tree_bdev+0x1d2/0x360 ext4_get_tree+0x19/0x30 vfs_get_tree+0x26/0xe0 path_mount+0x81d/0xfc0 do_mount+0x8d/0xc0 __x64_sys_mount+0xc0/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================================================Above issue may happen as follows:-------------------------------------ext4_fill_super ext4_orphan_cleanup ext4_enable_quotas ext4_quota_enable ext4_iget --> get error inode <5> ext4_ext_check_inode --> Wrong imode makes it escape inspection make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode dquot_load_quota_inode vfs_setup_quota_inode --> check pass dquot_load_quota_sb v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent __es_tree_search.isra.0 ext4_es_end --> Wrong extents trigger BUG_ONIn the above issue, s_usr_quota_inum is set to 5, but inode<5> containsincorrect imode and disordered extents. Because 5 is EXT4_BOOT_LOADER_INO,the ext4_ext_check_inode check in the ext4_iget function can be bypassed,finally, the extents that are not checked trigger the BUG_ON in the__es_tree_search function. To solve this issue, check whether the inode isbad_inode in vfs_setup_quota_inode().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-mfc: Clear workbit to handle error conditionDuring error on CLOSE_INSTANCE command, ctx_work_bits was not gettingcleared. During consequent mfc execution NULL pointer dereferencing ofthis context led to kernel panic. This patch fixes this issue by makingsure to clear ctx_work_bits always.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: devices: fix missing put_device in mport_cdev_openWhen kfifo_alloc fails, the refcount of chdev->dev is left incremental. We should use put_device(&chdev->dev) to decrease the ref count ofchdev->dev to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: mcb: fix resource leak in mcb_probe()When probe hook function failed in mcb_probe(), it doesn't put the device.Compiled test only.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: fix potential memory leak in wilc_mac_xmit()The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, adddev_kfree_skb() to fix it. Compile tested only.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: Fix potential resource leaksnfc_get_device() take reference for the device, add missingnfc_put_device() to release it when not need anymore.Also fix the style warnning by use error EOPNOTSUPP instead ofENOTSUPP.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: via-sdmmc: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value,it will lead two issues:1. The memory that allocated in mmc_alloc_host() is leaked.2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del().Fix this by checking the return value and goto error path whichwill call mmc_free_host().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: dio: fix possible memory leak in dio_init()If device_register() returns error, the 'dev' and name needs befreed. Add a release function, and then call put_device() in theerror path, so the name is freed in kobject_cleanup() and to the'dev' is freed in release function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: rio: fix possible name leak in rio_register_mport()If device_register() returns error, the name allocated by dev_set_name()need be freed. It should use put_device() to give up the reference in theerror path, so that the name can be freed in kobject_cleanup(), andlist_del() is called to delete the port from rio_mports.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix shift-out-of-bounds due to too large exponent of block sizeIf field s_log_block_size of superblock data is corrupted and too large,init_nilfs() and load_nilfs() still can trigger a shift-out-of-boundswarning followed by a kernel panic (if panic_on_warn is set): shift exponent 38973 is too large for 32-bit type 'int' Call Trace: dump_stack_lvl+0xcd/0x134 ubsan_epilogue+0xb/0x50 __ubsan_handle_shift_out_of_bounds.cold.12+0x17b/0x1f5 init_nilfs.cold.11+0x18/0x1d [nilfs2] nilfs_mount+0x9b5/0x12b0 [nilfs2] ...This fixes the issue by adding and using a new helper function for gettingblock size with sanity check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix a signed-integer-overflow bug in tcp_add_backlog()The type of sk_rcvbuf and sk_sndbuf in struct sock is int, andin tcp_add_backlog(), the variable limit is caculated by addingsk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max valueof int and overflow. This patch reduces the limit budget byhalving the sndbuf to solve this issue since ACK packets are muchsmaller than the payload.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: pxa: fix null-pointer dereference in filter()kasprintf() would return NULL pointer when kmalloc() fail to allocate.Need to check the return pointer before calling strcmp().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: OMAP2+: Fix memory leak in realtime_counter_init()The "sys_clk" resource is malloced by clk_get(),it is not released when the function return.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: musb: Fix musb_gadget.c rxstate overflow bugThe usb function device call musb_gadget_queue() adds the passedrequest to musb_ep::req_list,If the (request->length > musb_ep->packet_sz)and (is_buffer_mapped(req) return false),the rxstate() will copy all datain fifo to request->buf which may cause request->buf out of bounds.Fix it by add the length check :fifocnt = min_t(unsigned, request->length - request->actual, fifocnt);
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state()When peer delete failed in a disconnect operation, use-after-freedetected by KFENCE in below log. It is because for each vdev_id andaddress, it has only one struct ath10k_peer, it is allocated inath10k_peer_map_event(). When connected to an AP, it has more thanone HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then thearray peer_map of struct ath10k will be set muti-elements to thesame ath10k_peer in ath10k_peer_map_event(). When peer delete failedin ath10k_sta_state(), the ath10k_peer will be free for the 1st peerid in array peer_map of struct ath10k, and then use-after-free happenedfor the 2nd peer id because they map to the same ath10k_peer.And clean up all peers in array peer_map for the ath10k_peer, thenuser-after-free disappearedpeer map event log:[ 306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e[ 306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33[ 306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246[ 306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198[ 306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166peer unmap event log:[ 435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING)[ 435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone)[ 435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246[ 435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198[ 435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166use-after-free log:[21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING)[21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110[21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed[21713.799968] ==================================================================[21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core][21713.799991][21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69):[21713.800010] ath10k_sta_state+0x265/0xb8a [ath10k_core][21713.800041] drv_sta_state+0x115/0x677 [mac80211][21713.800059] __sta_info_destroy_part2+0xb1/0x133 [mac80211][21713.800076] __sta_info_flush+0x11d/0x162 [mac80211][21713.800093] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211][21713.800110] ieee80211_mgd_deauth+0x26c/0x29b [mac80211][21713.800137] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211][21713.800153] nl80211_deauthenticate+0xf8/0x121 [cfg80211][21713.800161] genl_rcv_msg+0x38e/0x3be[21713.800166] netlink_rcv_skb+0x89/0xf7[21713.800171] genl_rcv+0x28/0x36[21713.800176] netlink_unicast+0x179/0x24b[21713.800181] netlink_sendmsg+0x3a0/0x40e[21713.800187] sock_sendmsg+0x72/0x76[21713.800192] ____sys_sendmsg+0x16d/0x1e3[21713.800196] ___sys_sendmsg+0x95/0xd1[21713.800200] __sys_sendmsg+0x85/0xbf[21713.800205] do_syscall_64+0x43/0x55[21713.800210] entry_SYSCALL_64_after_hwframe+0x44/0xa9[21713.800213][21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k[21713.800219][21713.800224] allocated by task 13 on cpu 0 at 21705.501373s:[21713.800241] ath10k_peer_map_event+0x7e/0x154 [ath10k_core][21713.800254] ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core][21713.800265] ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core][21713.800277] ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core][21713.800283] ath10k_pci_process_rx_cb+0x195/0x1d---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix use-after-free in ath9k_hif_usb_disconnect()This patch fixes a use-after-free in ath9k that occurs inath9k_hif_usb_disconnect() when ath9k_destroy_wmi() is trying to access'drv_priv' that has already been freed by ieee80211_free_hw(), called byath9k_htc_hw_deinit(). The patch moves ath9k_destroy_wmi() beforeieee80211_free_hw(). Note that urbs from the driver should be killedbefore freeing 'wmi' with ath9k_destroy_wmi() as their callbacks willaccess 'wmi'.Found by a modified version of syzkaller.==================================================================BUG: KASAN: use-after-free in ath9k_destroy_wmi+0x38/0x40Read of size 8 at addr ffff8881069132a0 by task kworker/0:1/7CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #131Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x8e/0xd1 print_address_description.constprop.0.cold+0x93/0x334 ? ath9k_destroy_wmi+0x38/0x40 ? ath9k_destroy_wmi+0x38/0x40 kasan_report.cold+0x83/0xdf ? ath9k_destroy_wmi+0x38/0x40 ath9k_destroy_wmi+0x38/0x40 ath9k_hif_usb_disconnect+0x329/0x3f0 ? ath9k_hif_usb_suspend+0x120/0x120 ? usb_disable_interface+0xfc/0x180 usb_unbind_interface+0x19b/0x7e0 ? usb_autoresume_device+0x50/0x50 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30 ? __device_link_del+0x370/0x370 ? usb_remove_ep_devs+0x43/0x80 ? remove_intf_ep_devs+0x112/0x1a0 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950 ? rcu_read_lock_sched_held+0xa1/0xd0 ? hub_port_debounce+0x2e0/0x2e0 ? check_irq_usage+0x860/0xf20 ? drain_workqueue+0x281/0x360 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x92b/0x1460 ? pwq_dec_nr_in_flight+0x330/0x330 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x95/0xe00 ? __kthread_parkme+0x115/0x1e0 ? process_one_work+0x1460/0x1460 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30The buggy address belongs to the page:page:ffffea00041a44c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106913flags: 0x200000000000000(node=0|zone=2)raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 7, ts 38347963444, free_ts 41399957635 prep_new_page+0x1aa/0x240 get_page_from_freelist+0x159a/0x27c0 __alloc_pages+0x2da/0x6a0 alloc_pages+0xec/0x1e0 kmalloc_order+0x39/0xf0 kmalloc_order_trace+0x19/0x120 __kmalloc+0x308/0x390 wiphy_new_nm+0x6f5/0x1dd0 ieee80211_alloc_hw_nm+0x36d/0x2230 ath9k_htc_probe_device+0x9d/0x1e10 ath9k_htc_hw_init+0x34/0x50 ath9k_hif_usb_firmware_cb+0x25f/0x4e0 request_firmware_work_func+0x131/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480page last free stack trace: free_pcp_prepare+0x3d3/0x7f0 free_unref_page+0x1e/0x3d0 device_release+0xa4/0x240 kobject_put+0x186/0x4c0 put_device+0x20/0x30 ath9k_htc_disconnect_device+0x1cf/0x2c0 ath9k_htc_hw_deinit+0x26/0x30 ath9k_hif_usb_disconnect+0x2d9/0x3f0 usb_unbind_interface+0x19b/0x7e0 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950 process_one_work+0x92b/0x1460Memory state around the buggy address: ffff888106913180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888106913200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff>ffff888---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: Prevent drm_copy_field() to attempt copying a NULL pointerThere are some struct drm_driver fields that are required by drivers sincedrm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.But it can be possible that a driver has a bug and did not set some of thefields, which leads to drm_copy_field() attempting to copy a NULL pointer:[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000[ +0.010955] Mem abort info:[ +0.002835] ESR = 0x0000000096000004[ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits[ +0.005395] SET = 0, FnV = 0[ +0.003113] EA = 0, S1PTW = 0[ +0.003182] FSC = 0x04: level 0 translation fault[ +0.004964] Data abort info:[ +0.002919] ISV = 0, ISS = 0x00000004[ +0.003886] CM = 0, WnR = 0[ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000[ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[ +0.006925] Internal error: Oops: 96000004 [#1] SMP...[ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ +0.007061] pc : __pi_strlen+0x14/0x150[ +0.003895] lr : drm_copy_field+0x30/0x1a4[ +0.004156] sp : ffff8000094b3a50[ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040[ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040[ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000[ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000[ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40[ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8[ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141[ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000[ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000[ +0.007240] Call trace:[ +0.002475] __pi_strlen+0x14/0x150[ +0.003537] drm_version+0x84/0xac[ +0.003448] drm_ioctl_kernel+0xa8/0x16c[ +0.003975] drm_ioctl+0x270/0x580[ +0.003448] __arm64_sys_ioctl+0xb8/0xfc[ +0.003978] invoke_syscall+0x78/0x100[ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4[ +0.004767] do_el0_svc+0x38/0x4c[ +0.003357] el0_svc+0x34/0x100[ +0.003185] el0t_64_sync_handler+0x11c/0x150[ +0.004418] el0t_64_sync+0x190/0x194[ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)[ +0.006180] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failedThere is a null-ptr-deref when mount.cifs over rdma: BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046 CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: dump_stack_lvl+0x34/0x44 kasan_report+0xad/0x130 rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe] execute_in_process_context+0x25/0x90 __rxe_cleanup+0x101/0x1d0 [rdma_rxe] rxe_create_qp+0x16a/0x180 [rdma_rxe] create_qp.part.0+0x27d/0x340 ib_create_qp_kernel+0x73/0x160 rdma_create_qp+0x100/0x230 _smbd_get_connection+0x752/0x20f0 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0The root cause of the issue is the socket create failed inrxe_qp_init_req().So move the reset rxe_qp_do_cleanup() after the NULL ptr check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: toshsd: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value, the memorythat allocated in mmc_alloc_host() will be leaked and it will lead a kernelcrash because of deleting not added device in the remove path.So fix this by checking the return value and goto error path which will callmmc_free_host(), besides, free_irq() also needs be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()I got the the following report: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@62/regulators/extenIn of_get_regulator(), the node is returned from of_parse_phandle()with refcount incremented, after using it, of_node_put() need be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: Fix UAF in dm_integrity_dtr()Dm_integrity also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in dm_integrity_dtr().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in drivers/bluetooth/hci_ldisc.c in the Linux kernel 6.2. In hci_uart_tty_ioctl, there is a race condition between HCIUARTSETPROTO and HCIUARTGETPROTO. HCI_UART_PROTO_SET is set before hu->proto is set. A NULL pointer dereference may occur.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in drivers/mtd/ubi/cdev.c in the Linux kernel 6.2. There is a divide-by-zero error in do_div(sz,mtd->erasesize), used indirectly by ctrl_cdev_ioctl, when mtd->erasesize is 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.183.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: NCurse v6.4-20230418 was discovered to contain a segmentation fault via the component _nc_wrap_entry().
Packages affected:
- libncurses5 < 5.9-85.1 (version in image is 5.9-81.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.127.1 (version in image is 3.4.10-25.116.1).
-
Description: dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: avoid crash when parsed profile name is emptyWhen processing a packed profile in unpack_profile() described like "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"a string ":samba-dcerpcd" is unpacked as a fully-qualified name and thenpassed to aa_splitn_fqname().aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Lateraa_alloc_profile() crashes as the new profile name is NULL now.general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014RIP: 0010:strlen+0x1e/0xa0Call Trace: ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 ---[ end trace 0000000000000000 ]---RIP: 0010:strlen+0x1e/0xa0It seems such behaviour of aa_splitn_fqname() is expected and checked inother places where it is called (e.g. aa_remove_profiles). Well, thereis an explicit comment "a ns name without a following profile is allowed"inside.AFAICS, nothing can prevent unpacked "name" to be in form like":samba-dcerpcd" - it is passed from userspace.Deny the whole profile set replacement in such case and inform user withEPROTO and an explaining message.Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: Fix gluebi NULL pointer dereference caused by ftl notifierIf both ftl.ko and gluebi.ko are loaded, the notifier of ftltriggers NULL pointer dereference when trying to access'gluebi->desc' in gluebi_read().ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULLDetailed reproduction information available at the Link [1],In the normal case, obtain gluebi->desc in the gluebi_get_device(),and access gluebi->desc in the gluebi_read(). However,gluebi_get_device() is not executed in advance in theftl_add_mtd() process, which leads to NULL pointer dereference.The solution for the gluebi module is to run jffs2 on the UBIvolume without considering working with ftl or mtdblock [2].Therefore, this problem can be avoided by preventing gluebi fromcreating the mtdblock device after creating mtd partition of thetype MTD_UBIVOLUME.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/thunderx: Fix possible out-of-bounds string accessEnabling -Wstringop-overflow globally exposes a warning for a common bugin the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ...Apparently the author of this driver expected strncat() to behave theway that strlcat() does, which uses the size of the destination bufferas its third argument rather than the length of the source buffer. Theresult is that there is no check on the size of the allocated buffer.Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()check the alloc_workqueue return value in radeon_crtc_init()to avoid null-ptr-deref.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: hub: Guard against accesses to uninitialized BOS descriptorsMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.haccess fields inside udev->bos without checking if it was allocated andinitialized. If usb_get_bos_descriptor() fails for whateverreason, udev->bos will be NULL and those accesses will result in acrash:BUG: kernel NULL pointer dereference, address: 0000000000000018PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:hub_port_reset+0x193/0x788Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0Call Trace:hub_event+0x73f/0x156e? hub_activate+0x5b7/0x68fprocess_one_work+0x1a2/0x487worker_thread+0x11a/0x288kthread+0x13a/0x152? process_one_work+0x487/0x487? kthread_associate_blkcg+0x70/0x70ret_from_fork+0x1f/0x30Fall back to a default behavior if the BOS descriptor isn't accessibleand skip all the functionalities that depend on it: LPM support checks,Super Speed capabilitiy checks, U1/U2 states setup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: Don't unref the same fb many times by mistake due to deadlock handlingIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()we proceed to unref the fb and then retry the whole thing from the top.But we forget to reset the fb pointer back to NULL, and so if we thenget another error during the retry, before the fb lookup, we proceedthe unref the same fb again without having gotten another reference.The end result is that the fb will (eventually) end up being freedwhile it's still in use.Reset fb to NULL once we've unreffed it to avoid doing it againuntil we've done another fb lookup.This turned out to be pretty easy to hit on a DG2 when doing asyncflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom Isaw that drm_closefb() simply got stuck in a busy loop while walkingthe framebuffer list. Fortunately I was able to convince it to oopsinstead, and from there it was easier to track down the culprit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOThe SC16IS7XX IC supports a burst mode to access the FIFOs where theinitial register address is sent ($00), followed by all the FIFO datawithout having to resend the register address each time. In this mode, theIC doesn't increment the register address for each R/W byte.The regmap_raw_read() and regmap_raw_write() are functions which canperform IO over multiple registers. They are currently used to read/writefrom/to the FIFO, and although they operate correctly in this burst mode onthe SPI bus, they would corrupt the regmap cache if it was not disabledmanually. The reason is that when the R/W size is more than 1 byte, thesefunctions assume that the register address is incremented and handle thecache accordingly.Convert FIFO R/W functions to use the regmap _noinc_ versions in order toremove the manual cache control which was a workaround when using the_raw_ versions. FIFO registers are properly declared as volatile socache will not be used/updated for FIFO accesses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srp: Do not call scsi_done() from srp_abort()After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handlercallback, it performs one of the following actions:* Call scsi_queue_insert().* Call scsi_finish_command().* Call scsi_eh_scmd_add().Hence, SCSI abort handlers must not call scsi_done(). Otherwise allthe above actions would trigger a use-after-free. Hence remove thescsi_done() call from srp_abort(). Keep the srp_free_req() callbefore returning SUCCESS because we may not see the command again ifSUCCESS is returned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: llcp: Add lock when modifying device listThe device list needs its associated lock held when modifying it, or thelist could become corrupted, as syzbot discovered.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()Including the transhdrlen in length is a problem when the packet ispartially filled (e.g. something like send(MSG_MORE) happened previously)when appending to an IPv4 or IPv6 packet as we don't want to repeat thetransport header or account for it twice. This can happen under somecircumstances, such as splicing into an L2TP socket.The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800that occurs when MSG_SPLICE_PAGES is used to append more data to an alreadypartially occupied skbuff. The warning occurs when 'copy' is larger thanthe amount of data in the message iterator. This is because the requestedlength includes the transport header length when it shouldn't. This can betriggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024);Fix this by only adding transhdrlen into the length if the write queue isempty in l2tp_ip6_sendmsg(), analogously to how UDP does things.l2tp_ip_sendmsg() looks like it won't suffer from this problem as it buildsthe UDP packet itself.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix potential key use-after-freeWhen ieee80211_key_link() is called by ieee80211_gtk_rekey_add()but returns 0 due to KRACK protection (identical key reinstall),ieee80211_gtk_rekey_add() will still return a pointer into thekey, in a potential use-after-free. This normally doesn't happensince it's only called by iwlwifi in case of WoWLAN rekey offloadwhich has its own KRACK protection, but still better to fix, dothat by returning an error code and converting that to success onthe cfg80211 boundary only, leaving the error for bad callers ofieee80211_gtk_rekey_add().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: Fix a memory corruption issueA few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate)'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine.At the end of this structure, there is the 'channels' flex array.Each element is of type 'struct ieee80211_channel'.So only 1 element is allocated in this array.When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels;We point at the first element of the 'channels' flex array.So this is fine.However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1);because of the "(u8 *)" cast, we add only 1 to the address of the beginningof the flex array.It is likely that we want point at the 'struct ieee80211_rate' allocatedjust after.Remove the spurious casting so that the pointer arithmetic works asexpected.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix TX CQE error handlingFor an unknown TX CQE error type (probably from a newer hardware),still free the SKB, update the queue tail, etc., otherwise theaccounting will be wrong.Also, TX errors can be triggered by injecting corrupted packets, soreplace the WARN_ONCE to ratelimited error logging.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix null-ptr-deref when team device type is changedGet a null-ptr-deref bug as follows with reproducer [1].BUG: kernel NULL pointer dereference, address: 0000000000000228...RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]...Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30[1]$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'$ ip link add name t-dummy type dummy$ ip link add link t-dummy name t-dummy.100 type vlan id 100$ ip link add name t-nlmon type nlmon$ ip link set t-nlmon master team0$ ip link set t-nlmon nomaster$ ip link set t-dummy up$ ip link set team0 up$ ip link set t-dummy.100 down$ ip link set t-dummy.100 master team0When enslave a vlan device to team device and team device type is changedfrom non-ether to ether, header_ops of team device is changed tovlan_header_ops. That is incorrect and will trigger null-ptr-dereffor vlan->real_dev in vlan_dev_hard_header() because team device is nota vlan device.Cache eth_header_ops in team_setup(), then assign cached header_ops toheader_ops of team net device when its type is changed from non-etherto ether to fix the bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix deadlock or deadcode of misusing dget()The lock order is incorrect between denty and its parent, we shouldalways make sure that the parent get the lock first.But since this deadcode is never used and the parent dir will alwaysbe set from the callers, let's just remove it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ptrace: handle setting of fpc register correctlyIf the content of the floating point control (fpc) register of a tracedprocess is modified with the ptrace interface the new value is tested forvalidity by temporarily loading it into the fpc register.This may lead to corruption of the fpc register of the tracing process:if an interrupt happens while the value is temporarily loaded into thefpc register, and within interrupt context floating point or vectorregisters are used, the current fp/vx registers are saved withsave_fpu_regs() assuming they belong to user space and will be loaded intofp/vx registers when returning to user space.test_fp_ctl() restores the original user space fpc register value, howeverit will be discarded, when returning to user space.In result the tracer will incorrectly continue to run with the value thatwas supposed to be used for the traced process.Fix this by saving fpu register contents with save_fpu_regs() before usingtest_fp_ctl().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/mm: Fix null-pointer dereference in pgtable_cache_addkasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pstore/ram: Fix crash when setting number of cpus to an odd numberWhen the number of cpu cores is adjusted to 7 or other odd numbers,the zone size will become an odd number.The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ...The address of zone1/3/5/7 will be mapped to non-alignment va.Eventually crashes will occur when accessing these va.So, use ALIGN_DOWN() to make sure the zone size is evento avoid this bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix a suspicious RCU usage warningI received the following warning while running cthon against an ontapserver running pNFS:[ 57.202521] =============================[ 57.202522] WARNING: suspicious RCU usage[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted[ 57.202525] -----------------------------[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!![ 57.202527] other info that might help us debug this:[ 57.202528] rcu_scheduler_active = 2, debug_locks = 1[ 57.202529] no locks held by test5/3567.[ 57.202530] stack backtrace:[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022[ 57.202536] Call Trace:[ 57.202537] [ 57.202540] dump_stack_lvl+0x77/0xb0[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202866] write_cache_pages+0x265/0x450[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202913] do_writepages+0xd2/0x230[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80[ 57.202924] filemap_write_and_wait_range+0xd9/0x170[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202969] __se_sys_close+0x46/0xd0[ 57.202972] do_syscall_64+0x68/0x100[ 57.202975] ? do_syscall_64+0x77/0x100[ 57.202976] ? do_syscall_64+0x77/0x100[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76[ 57.202982] RIP: 0033:0x7fe2b12e4a94[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49[ 57.202993] R10: 00007f---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Synchronize devfreq_monitor_[start/stop]There is a chance if a frequent switch of the governordone in a loop result in timer list corruption wheretimer cancel being done from two place one fromcancel_delayed_work_sync() and followed by expire_timers()can be seen from the traces[1].while truedo echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governordoneIt looks to be issue with devfreq driver wheredevice_monitor_[start/stop] need to synchronized so thatdelayed work should get corrupted while it is eitherbeing queued or running or being cancelled.Let's use polling flag and devfreq lock to synchronize thequeueing the timer instance twice and work data beingcorrupted.[1].....-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428[2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a[ 9436.261664][ C4] Mem abort info:[ 9436.261666][ C4] ESR = 0x96000044[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits[ 9436.261671][ C4] SET = 0, FnV = 0[ 9436.261673][ C4] EA = 0, S1PTW = 0[ 9436.261675][ C4] Data abort info:[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044[ 9436.261680][ C4] CM = 0, WnR = 1[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0...[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438[ 9436.262168][ C4] sp : ffffffc010023dd0[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: s390: vsie: fix race during shadow creationRight now it is possible to see gmap->private being zero inkvm_s390_vsie_gmap_notifier resulting in a crash. This is due to thefact that we add gmap->private == kvm after creation:static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page){[...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm;Let children inherit the private field of the parent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabledWhen QoS is disabled, the queue priority value will not map to the correctieee80211 queue since there is only one queue. Stop/wake queue 0 when QoSis disabled to prevent trying to stop/wake a non-existent queue and failingto stop/wake the actual queue instantiated.Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:aio: fix mremap after fork null-derefCommit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduceda null-deref if mremap is called on an old aio mapping after fork asmm->ioctx_table will be set to NULL.[jmoyer@redhat.com: fix 80 column issue]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: dsi: Add missing check for of_find_device_by_nodeAdd check for the return value of of_find_device_by_node() and returnthe error if it fails in order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: eliminate double free in error handling logicDriver has a logic leak in ring data allocation/free,where aq_ring_free could be called multiple times on same ring,if system is under stress and got memory allocation error.Ring pointer was used as an indicator of failure, but this isnot correct since only ring data is allocated/deallocated.Ring itself is an array member.Changing ring allocation functions to return error code directly.This simplifies error handling and eliminates aq_ring_freeon higher layer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: s390/aes - Fix buffer overread in CTR modeWhen processing the last block, the s390 ctr code will always reada whole block, even if there isn't a whole block of data left. Fixthis by using the actual length left and copy it into a buffer firstfor processing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/imc-pmu: Add a null pointer check in update_events_in_group()kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: LPIT: Avoid u32 multiplication overflowIn lpit_update_residency() there is a possibility of overflowin multiplication, if tsc_khz is large enough (> UINT_MAX/1000).Change multiplication to mul_u32_u32().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/powernv: Add a null pointer check in opal_event_init()kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix a double-free in si_dpm_initWhen the allocation ofadev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,amdgpu_free_extended_power_table is called to free some fields of adev.However, when the control flow returns to si_dpm_sw_init, it goes tolabel dpm_failed and calls si_dpm_fini, which callsamdgpu_free_extended_power_table again and free those fields again. Thusa double-free is triggered.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: check for error while searching for backlight device parentIf acpi_get_parent() called in acpi_video_dev_register_backlight()fails, for example, because acpi_ut_acquire_mutex() fails insideacpi_get_parent), this can lead to incorrect (uninitialized)acpi_parent handle being passed to acpi_get_pci_dev() for detectingthe parent pci device.Check acpi_get_parent() result and set parent device only in case of success.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/powernv: Add a null pointer check in opal_powercap_init()kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix underflow in second superblock position calculationsMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the secondsuperblock, underflows when the argument device size is less than 4096bytes. Therefore, when using this macro, it is necessary to check inadvance that the device size is not less than a lower limit, or at leastthat underflow does not occur.The current nilfs2 implementation lacks this check, causing out-of-boundblock access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)In addition, when trying to resize the filesystem to a size below 4096bytes, this underflow occurs in nilfs_resize_fs(), passing a huge numberof segments to nilfs_sufile_resize(), corrupting parameters such as thenumber of segments in superblocks. This causes excessive loop iterationsin nilfs_sufile_resize() during a subsequent resize ioctl, causingsemaphore ns_segctor_sem to block for a long time and hang the writerthread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 ... Call Trace: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...This fixes these issues by inserting appropriate minimum device sizechecks or anti-underflow checks, depending on where the macro is used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: mmc_spi: fix error handling in mmc_spi_probe()If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),or it will cause null-ptr-deref, because of deleting a not addeddevice in mmc_remove_host().To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,and change the label 'fail_add_host' to 'fail_gpiod_request'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: blocklist the kclient when receiving corrupted snap traceWhen received corrupted snap trace we don't know what exactly hashappened in MDS side. And we shouldn't continue IOs and metadatasaccess to MDS, which may corrupt or get incorrect contents.This patch will just block all the further IO/MDS requestsimmediately and then evict the kclient itself.The reason why we still need to evict the kclient just afterblocking all the further IOs is that the MDS could revoke the capsfaster.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: lock the inode in shared mode before starting fiemapCurrently fiemap does not take the inode's lock (VFS lock), it only locksa file range in the inode's io tree. This however can lead to a deadlockif we have a concurrent fsync on the file and fiemap code triggers a faultwhen accessing the user space buffer with fiemap_fill_next_extent(). Thedeadlock happens on the inode's i_mmap_lock semaphore, which is taken bothby fsync and btrfs_page_mkwrite(). This deadlock was recently reported bysyzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix use-after-free in rdata->read_into_pages()When the network status is unstable, use-after-free may occur whenread data from the server. BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0 Call Trace: dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50The following function calls will cause UAF of the rdata pointer.readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages()Similarly, this problem also occurs in the uncache_fill_pages().Fix this by adjusts the order of condition judgment in the returnstatement.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: USB: Fix wrong-direction WARNING in plusb.cThe syzbot fuzzer detected a bug in the plusb network driver: Azero-length control-OUT transfer was treated as a read instead of awrite. In modern kernels this error provokes a WARNING:usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411Modules linked in:CPU: 1 PID: 4645 Comm: dhcpcd Not tainted6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google01/12/2023RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411...Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() andremove the USB_DIR_IN flag.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid NULL dereference of timing generator[Why & How]Check whether assigned timing generator is NULL or not beforeaccessing its funcs to prevent NULL dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: imon: fix access to invalid resource for the second interfaceimon driver probes two USB interfaces, and at the probe of the secondinterface, the driver assumes blindly that the first interface gotbound with the same imon driver. It's usually true, but it's stillpossible that the first interface is bound with another driver via amalformed descriptor. Then it may lead to a memory corruption, asspotted by syzkaller; imon driver accesses the data from drvdata asstruct imon_context object although it's a completely different onethat was assigned by another driver.This patch adds a sanity check -- whether the first interface isreally bound with the imon driver or not -- for avoiding the problemabove at the probe time.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when releasing midsAll release_mid() callers seem to hold a reference of @mid so there isno need to call kref_put(&mid->refcount, __release_mid) under@server->mid_lock spinlock. If they don't, then an use-after-free bugwould have occurred anyways.By getting rid of such spinlock also fixes a potential deadlock asshown belowCPU 0 CPU 1------------------------------------------------------------------cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&server->mid_lock); spin_lock(&cifs_tcp_ses_lock) spin_lock(&server->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *deadlock*
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-blk: fix implicit overflow on virtio_max_dma_sizeThe following codes have an implicit conversion from size_t to u32:(u32)max_size = (size_t)virtio_max_dma_size(vdev);This may lead overflow, Ex (size_t)4G -> (u32)0. Oncevirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAXinstead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: gspca: cpia1: shift-out-of-bounds in set_flickerSyzkaller reported the following issue:UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27shift exponent 245 is too large for 32-bit type 'int'When the value of the variable "sd->params.exposure.gain" exceeds thenumber of bits in an integer, a shift-out-of-bounds error is reported. Itis triggered because the variable "currentexp" cannot be left-shifted bymore than the number of bits in an integer. In order to avoid invalidrange during left-shift, the conditional expression is added.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/dasd: protect device queue against concurrent accessIn dasd_profile_start() the amount of requests on the device queue arecounted. The access to the device queue is unprotected againstconcurrent access. With a lot of parallel I/O, especially with aliasdevices enabled, the device queue can change while dasd_profile_start()is accessing the queue. In the worst case this leads to a kernel panicdue to incorrect pointer accesses.Fix this by taking the device lock before accessing the queue andcounting the requests. Additionally the check for a valid profile datapointer can be done earlier to avoid unnecessary locking in a hot path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: add ipvlan_route_v6_outbound() helperInspired by syzbot reports using a stack of multiple ipvlan devices.Reduce stack size needed in ipvlan_process_v6_outbound() by movingthe flowi6 struct used for the route lookup in an non inlinedhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,immediately reclaimed.Also make sure ipvlan_process_v4_outbound() is not inlined.We might also have to lower MAX_NEST_DEV, because only syzbot usessetups with more than four stacked devices.BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)stack guard page: 0000 [#1] SMP KASANCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89RSP: 0018:ffffc9000e804000 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080cR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:<#DF>
[] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31[] instrument_atomic_read include/linux/instrumented.h:72 [inline][] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline][] cpumask_test_cpu include/linux/cpumask.h:506 [inline][] cpu_online include/linux/cpumask.h:1092 [inline][] trace_lock_acquire include/trace/events/lock.h:24 [inline][] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632[] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306[] rcu_read_lock include/linux/rcupdate.h:747 [inline][] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221[] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606[] pol_lookup_func include/net/ip6_fib.h:584 [inline][] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116[] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638[] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651[] ip6_route_output include/net/ip6_route.h:100 [inline][] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4966 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324[] dev_queue_xmit include/linux/netdevice.h:3067 [inline][] neigh_hh_output include/net/neighbour.h:529 [inline][
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfsIf init debugfs failed during device registration due to memory allocationfailure, debugfs_remove_recursive() is called, after which debugfs_dir isnot set to NULL. debugfs_remove_recursive() will be called again duringdevice removal. As a result, illegal pointer is accessed.[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!...[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 1669.872669] pc : down_write+0x24/0x70[ 1669.876315] lr : down_write+0x1c/0x70[ 1669.879961] sp : ffff000036f53a30[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001[ 1669.962563] Call trace:[ 1669.965000] down_write+0x24/0x70[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main][ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw][ 1669.984175] pci_device_remove+0x48/0xd8[ 1669.988082] device_release_driver_internal+0x1b4/0x250[ 1669.993282] device_release_driver+0x28/0x38[ 1669.997534] pci_stop_bus_device+0x84/0xb8[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40[ 1670.007244] remove_store+0xfc/0x140[ 1670.010802] dev_attr_store+0x44/0x60[ 1670.014448] sysfs_kf_write+0x58/0x80[ 1670.018095] kernfs_fop_write+0xe8/0x1f0[ 1670.022000] __vfs_write+0x60/0x190[ 1670.025472] vfs_write+0xac/0x1c0[ 1670.028771] ksys_write+0x6c/0xd8[ 1670.032071] __arm64_sys_write+0x24/0x30[ 1670.035977] el0_svc_common+0x78/0x130[ 1670.039710] el0_svc_handler+0x38/0x78[ 1670.043442] el0_svc+0x8/0xcTo fix this, set debugfs_dir to NULL after debugfs_remove_recursive().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()fc_lport_ptp_setup() did not check the return value of fc_rport_create()which can return NULL and would cause a NULL pointer dereference. Addressthis issue by checking return value of fc_rport_create() and log errormessage on fc_rport_create() failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst->flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon't call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&wait->completion), which will causehungtask.The problem comes as following:(padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULLIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:1. Navigate to the directory: /sys/kernel/debug/dri/02. Execute command: cat amdgpu_regs_smc3. Exception Log::[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000[4005007.702562] #PF: supervisor instruction fetch in kernel mode[4005007.702567] #PF: error_code(0x0010) - not-present page[4005007.702570] PGD 0 P4D 0[4005007.702576] Oops: 0010 [#1] SMP NOPTI[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u[4005007.702590] RIP: 0010:0x0[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0[4005007.702633] Call Trace:[4005007.702636] [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu][4005007.703002] full_proxy_read+0x5c/0x80[4005007.703011] vfs_read+0x9f/0x1a0[4005007.703019] ksys_read+0x67/0xe0[4005007.703023] __x64_sys_read+0x19/0x20[4005007.703028] do_syscall_64+0x5c/0xc0[4005007.703034] ? do_user_addr_fault+0x1e3/0x670[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20[4005007.703052] ? irqentry_exit+0x19/0x30[4005007.703057] ? exc_page_fault+0x89/0x160[4005007.703062] ? asm_exc_page_fault+0x8/0x30[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae[4005007.703075] RIP: 0033:0x7f5e07672992[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000[4005007.703105] [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca[4005007.703184] CR2: 0000000000000000[4005007.703188] ---[ en---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panel: fix a possible null pointer dereferenceIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't return unset power in ieee80211_get_tx_power()We can get a UBSAN warning if ieee80211_get_tx_power() returns theINT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211]In this case, simply return an error instead, to indicatethat no data is available.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:llc: verify mac len before reading mac headerLLC reads the mac header with eth_hdr without verifying that the skbhas an Ethernet header.Syzbot was able to enter llc_rcv on a tun device. Tun can insertpackets without mac len and with user configurable skb->protocol(passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002Add a mac_len test before all three eth_hdr(skb) calls under net/llc.There are further uses in include/net/llc_pdu.h. All these areprotected by a test skb->protocol == ETH_P_802_2. Which does notprotect against this tun scenario.But the mac_len test added in this patch in llc_fixup_skb willindirectly protect those too. That is called from llc_rcv before anyother LLC code.It is tempting to just add a blanket mac_len check in llc_rcv, butnot sure whether that could break valid LLC paths that do not assumean Ethernet header. 802.2 LLC may be used on top of non-802.3protocols in principle. The below referenced commit shows that usedto, on top of Token Ring.At least one of the three eth_hdr uses goes back to before the startof git history. But the one that syzbot exercises is introduced inthis commit. That commit is old enough (2008), that effectively allstable kernels should receive this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Change nla_policy for bearer-related names to NLA_NUL_STRINGsyzbot reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdTIPC bearer-related names including link names must be null-terminatedstrings. If a link name which is not null-terminated is passed throughnetlink, strstr() and similar functions can cause buffer overrun. Thiscauses the above issue.This patch changes the nla_policy for bearer-related names from NLA_STRINGto NLA_NUL_STRING. This resolves the issue by ensuring that onlynull-terminated strings are accepted as bearer-related names.syzbot reported similar uninit-value issue related to bearer names [2]. Theroot cause of this issue is that a non-null-terminated bearer name waspassed. This patch also resolved this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix refcnt handling in padata_free_shell()In a high-load arm64 environment, the pcrypt_aead01 test in LTP can leadto system UAF (Use-After-Free) issues. Due to the lengthy analysis ofthe pcrypt_aead01 function call, I'll describe the problem scenariousing a simplified model:Suppose there's a user of padata named `user_function` that adheres tothe padata requirement of calling `padata_free_shell` after `serial()`has been invoked, as demonstrated in the following code:```cstruct request { struct padata_priv padata; struct completion *done;};void parallel(struct padata_priv *padata) { do_something();}void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done);}void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell();}```In the corresponding padata.c file, there's the following code:```cstatic void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd);}```Because of the high system load and the accumulation of unexecutedsoftirq at this moment, `local_bh_enable()` in padata takes longerto execute than usual. Subsequently, when accessing `pd->refcnt`,`pd` has already been released by `padata_free_shell()`, resultingin a UAF issue with `pd->refcnt`.The fix is straightforward: add `refcount_dec_and_test` before calling`padata_free_pd` in `padata_free_shell`.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc2: fix possible NULL pointer dereference caused by driver concurrencyIn _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed withoutholding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ...out: spin_unlock_irqrestore(&hsotg->lock, flags);When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() areconcurrently executed, the NULL check of "urb->hcpriv" can be executedbefore "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be usedin the function call to dwc2_hcd_urb_dequeue(), which can cause a NULLpointer dereference.This possible bug is found by an experimental static analysis tooldeveloped by myself. This tool analyzes the locking APIs to extractfunction pairs that can be concurrently executed, and then analyzes theinstructions in the paired functions to identify possible concurrencybugs including data races and atomicity violations. The above possiblebug is reported, when my tool analyzes the source code of Linux 6.5.To fix this possible bug, "urb->hcpriv = NULL" should be executed withholding the lock "hsotg->lock". After using this patch, my tool neverreports the possible bug, with the kernelconfiguration allyesconfig forx86_64. Because I have no associated hardware, I cannot test the patchin runtime testing, and just verify it according to the code logic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: wmi: Fix opening of char deviceSince commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer viafile private data"), the miscdevice stores a pointer to itself insidefilp->private_data, which means that private_data will not be NULL whenwmi_char_open() is called. This might cause memory corruption shouldwmi_char_open() be unable to find its driver, something which canhappen when the associated WMI device is deleted in wmi_free_devices().Fix the problem by using the miscdevice pointer to retrieve the WMIdevice data associated with a char device using container_of(). Thisalso avoids wmi_char_open() picking a wrong WMI device bound to adriver with the same name as the original driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of boundsIf the "struct can_priv::echoo_skb" is accessed out of bounds, thiswould cause a kernel crash. Instead, issue a meaningful warningmessage and return with an error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gsmi: fix null-deref in gsmi_get_variableWe can get EFI variables without fetching the attribute, so we mustallow for that in gsmi.commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstoreaccess layer") added a new get_variable call with attr=NULL, whichtriggers panic in gsmi.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Check endpoint is valid before dereferencing itWhen the host controller is not responding, all URBs queued to allendpoints need to be killed. This can cause a kernel panic if wedereference an invalid endpoint.Fix this by using xhci_get_virt_ep() helper to find the endpoint andchecking if the endpoint is valid before dereferencing it.[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8[233311.853964] pc : xhci_hc_died+0x10c/0x270[233311.853971] lr : xhci_hc_died+0x1ac/0x270[233311.854077] Call trace:[233311.854085] xhci_hc_died+0x10c/0x270[233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4[233311.854105] call_timer_fn+0x50/0x2d4[233311.854112] expire_timers+0xac/0x2e4[233311.854118] run_timer_softirq+0x300/0xabc[233311.854127] __do_softirq+0x148/0x528[233311.854135] irq_exit+0x194/0x1a8[233311.854143] __handle_domain_irq+0x164/0x1d0[233311.854149] gic_handle_irq.22273+0x10c/0x188[233311.854156] el1_irq+0xfc/0x1a8[233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm][233311.854185] cpuidle_enter_state+0x1f0/0x764[233311.854194] do_idle+0x594/0x6ac[233311.854201] cpu_startup_entry+0x7c/0x80[233311.854209] secondary_start_kernel+0x170/0x198
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()Fix a use-after-free that occurs in hcd when in_urb sent frompn533_usb_send_frame() is completed earlier than out_urb. Its callbackfrees the skb data in pn533_send_async_complete() that is used as atransfer buffer of out_urb. Wait before sending in_urb until thecallback of out_urb is called. To modify the callback of out_urb alone,separate the complete function of out_urb and ack_urb.Found by a modified version of syzkaller.BUG: KASAN: use-after-free in dummy_timerCall Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xferIn af9035_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9035_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: check cx23885_vdev_init() returncx23885_vdev_init() can return a NULL pointer, but that pointeris used in the next line without a check.Add a NULL pointer check and go to the error unwind if it is NULL.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: fix possible NULL pointer dereference in send_acknowledge()Handle memory allocation failure from nci_skb_alloc() (callingalloc_skb()) to avoid possible NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix handling and sanity checking of xattr_ids countA Sysbot [1] corrupted filesystem exposes two flaws in the handling andsanity checking of the xattr_ids count in the filesystem. Both of theseflaws cause computation overflow due to incorrect typing.In the corrupted filesystem the xattr_ids value is 4294967071, whichstored in a signed variable becomes the negative number -225.Flaw 1 (64-bit systems only):The signed integer xattr_ids variable causes sign extension.This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. Thevariable is first multiplied by sizeof(struct squashfs_xattr_id) where thetype of the sizeof operator is "unsigned long".On a 64-bit system this is 64-bits in size, and causes the negative numberto be sign extended and widened to 64-bits and then become unsigned. Thisproduces the very large number 18446744073709548016 or 2^64 - 3600. Thisnumber when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) anddivided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0(stored in len).Flaw 2 (32-bit systems only):On a 32-bit system the integer variable is not widened by the unsignedlong type of the sizeof operator (32-bits), and the signedness of thevariable has no effect due it always being treated as unsigned.The above corrupted xattr_ids value of 4294967071, when multipliedoverflows and produces the number 4294963696 or 2^32 - 3400. This numberwhen rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided bySQUASHFS_METADATA_SIZE overflows again and produces a length of 0.The effect of the 0 length computation:In conjunction with the corrupted xattr_ids field, the filesystem also hasa corrupted xattr_table_start value, where it matches the end offilesystem value of 850.This causes the following sanity check code to fail because theincorrectly computed len of 0 matches the incorrect size of the tablereported by the superblock (0 bytes). len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids); indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids); /* * The computed size of the index table (len bytes) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_used; if (len != (end - start)) return ERR_PTR(-EINVAL);Changing the xattr_ids variable to be "usigned int" fixes the flaw on a64-bit system. This relies on the fact the computation is widened by theunsigned long type of the sizeof operator.Casting the variable to u64 in the above macro fixes this flaw on a 32-bitsystem.It also means 64-bit systems do not implicitly rely on the type of thesizeof operator to widen the computation.[1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/khugepaged: fix ->anon_vma raceIf an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requiresit to be locked.Page table traversal is allowed under any one of the mmap lock, theanon_vma lock (if the VMA is associated with an anon_vma), and themapping lock (if the VMA is associated with a mapping); and so to beable to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but doesthis check before holding the mmap lock (as the comment above the checkexplains).If we racily merged an existing ->anon_vma (shared with a childprocess) from a neighboring VMA, subsequent rmap traversals on pagesbelonging to the child will be able to see the page tables that we areconcurrently removing while assuming that nothing else can access them.Repeat the ->anon_vma check once we hold the mmap lock to ensure thatthere really is no concurrent page table access.Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAFAfter a call to console_unlock() in vcs_read() the vc_data struct can befreed by vc_deallocate(). Because of that, the struct vc_data pointerload must be done at the top of while loop in vcs_read() to avoid a UAFwhen vcs_size() is called.Syzkaller reported a UAF in vcs_size().BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1Hardware name: Red Hat KVM, BIOS 1.15.0-2.moduleCall Trace: __asan_report_load4_noabort (mm/kasan/report_generic.c:350)vcs_size (drivers/tty/vt/vc_screen.c:215)vcs_read (drivers/tty/vt/vc_screen.c:415)vfs_read (fs/read_write.c:468 fs/read_write.c:450)... Allocated by task 1191:...kmalloc_trace (mm/slab_common.c:1069)vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720 drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)con_install (drivers/tty/vt/vt.c:3383)tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413 drivers/tty/tty_io.c:1390)tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)chrdev_open (fs/char_dev.c:415)do_dentry_open (fs/open.c:883)vfs_open (fs/open.c:1014)...Freed by task 1548:...kfree (mm/slab_common.c:1021)vc_port_destruct (drivers/tty/vt/vt.c:1094)tty_port_destructor (drivers/tty/tty_port.c:296)tty_port_put (drivers/tty/tty_port.c:312)vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)tty_ioctl (drivers/tty/tty_io.c:2776)...The buggy address belongs to the object at ffff888113747800 which belongs to the cache kmalloc-1k of size 1024The buggy address is located 424 bytes inside of 1024-byte region [ffff888113747800, ffff888113747c00)The buggy address belongs to the physical page:page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x113740head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0 compound_pincount:0anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb> ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================Disabling lock debugging due to kernel taint
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddressIf during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,userspace could be accessing the host's ipaddress attr. If we then free thesession via iscsi_session_teardown() while userspace is still accessing thesession we will hit a use after free bug.Set the tcp_sw_host->session after we have completed session creation andcan no longer fail.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddressBug report and analysis from Ding Hui.During iSCSI session logout, if another task accesses the shost ipaddressattr, we can get a KASAN UAF report like this:[ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0[ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088[ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3[ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020[ 276.944470] Call Trace:[ 276.944943] [ 276.945397] dump_stack_lvl+0x34/0x48[ 276.945887] print_address_description.constprop.0+0x86/0x1e7[ 276.946421] print_report+0x36/0x4f[ 276.947358] kasan_report+0xad/0x130[ 276.948234] kasan_check_range+0x35/0x1c0[ 276.948674] _raw_spin_lock_bh+0x78/0xe0[ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp][ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi][ 276.952185] dev_attr_show+0x3f/0x80[ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0[ 276.953401] seq_read_iter+0x402/0x1020[ 276.954260] vfs_read+0x532/0x7b0[ 276.955113] ksys_read+0xed/0x1c0[ 276.955952] do_syscall_64+0x38/0x90[ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 276.956769] RIP: 0033:0x7f5d3a679222[ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24[ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000[ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222[ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003[ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000[ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000[ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58[ 276.960536] [ 276.961357] Allocated by task 2209:[ 276.961756] kasan_save_stack+0x1e/0x40[ 276.962170] kasan_set_track+0x21/0x30[ 276.962557] __kasan_kmalloc+0x7e/0x90[ 276.962923] __kmalloc+0x5b/0x140[ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi][ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi][ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp][ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi][ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi][ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi][ 276.965546] netlink_unicast+0x4d5/0x7b0[ 276.965905] netlink_sendmsg+0x78d/0xc30[ 276.966236] sock_sendmsg+0xe5/0x120[ 276.966576] ____sys_sendmsg+0x5fe/0x860[ 276.966923] ___sys_sendmsg+0xe0/0x170[ 276.967300] __sys_sendmsg+0xc8/0x170[ 276.967666] do_syscall_64+0x38/0x90[ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 276.968773] Freed by task 2209:[ 276.969111] kasan_save_stack+0x1e/0x40[ 276.969449] kasan_set_track+0x21/0x30[ 276.969789] kasan_save_free_info+0x2a/0x50[ 276.970146] __kasan_slab_free+0x106/0x190[ 276.970470] __kmem_cache_free+0x133/0x270[ 276.970816] device_release+0x98/0x210[ 276.971145] kobject_cleanup+0x101/0x360[ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi][ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp][ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi][ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi][ 276.972808] netlink_unicast+0x4d5/0x7b0[ 276.973201] netlink_sendmsg+0x78d/0xc30[ 276.973544] sock_sendmsg+0xe5/0x120[ 276.973864] ____sys_sendmsg+0x5fe/0x860[ 276.974248] ___sys_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()snd_hda_get_connections() can return a negative error code.It may lead to accessing 'conn' array at a negative index.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP regionThis patch is fix for Linux kernel v2.6.33 or later.For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystemhave had an issue of use-after-free. The subsystem allows multipleuser space listeners to the region, while data of the payload was likelyreleased before the listeners execute read(2) to access to it for copyingto user space.The issue was fixed by a commit 281e20323ab7 ("firewire: core: fixuse-after-free regression in FCP handler"). The object of payload isduplicated in kernel space for each listener. When the listener executesioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going tobe released.However, it causes memory leak since the commit relies on call ofrelease_request() in drivers/firewire/core-cdev.c. Against theexpectation, the function is never called due to the design ofrelease_client_resource(). The function delegates release taskto caller when called with non-NULL fourth argument. The implementationof ioctl_send_response() is the case. It should release the objectexplicitly.This commit fixes the bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/i8259: Mark legacy PIC interrupts with IRQ_LEVELBaoquan reported that after triggering a crash the subsequent crash-kernelfails to boot about half of the time. It triggers a NULL pointerdereference in the periodic tick code.This happens because the legacy timer interrupt (IRQ0) is resent insoftware which happens in soft interrupt (tasklet) context. In this contextget_irq_regs() returns NULL which leads to the NULL pointer dereference.The reason for the resend is a spurious APIC interrupt on the IRQ0 vectorwhich is captured and leads to a resend when the legacy timer interrupt isenabled. This is wrong because the legacy PIC interrupts are leveltriggered and therefore should never be resent in software, but nothingever sets the IRQ_LEVEL flag on those interrupts, so the core code does notknow about their trigger type.Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val;@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: prevent potential spectre v1 gadgetsMost netlink attributes are parsed and validated from__nla_validate_parse() or validate_nla() u16 type = nla_type(nla); if (type == 0 || type > maxtype) { /* error or continue */ }@type is then used as an array index and can be usedas a Spectre v1 gadget.array_index_nospec() can be used to prevent leakingcontent of kernel memory to malicious users.This should take care of vast majority of netlink uses,but an audit is needed to take care of others wherevalidation is not yet centralized in core netlink functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix oops due to uncleared server->smbd_conn in reconnectIn smbd_destroy(), clear the server->smbd_conn pointer after freeing thesmbd_connection struct that it points to so that reconnection doesn't getconfused.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Make sure trace_printk() can output as soon as it can be usedCurrently trace_printk() can be used as soon as early_trace_init() iscalled from start_kernel(). But if a crash happens, and"ftrace_dump_on_oops" is set on the kernel command line, all you get willbe: [ 0.456075] -0 0dN.2. 347519us : Unknown type 6 [ 0.456075] -0 0dN.2. 353141us : Unknown type 6 [ 0.456075] -0 0dN.2. 358684us : Unknown type 6This is because the trace_printk() event (type 6) hasn't been registeredyet. That gets done via an early_initcall(), which may be early, but notearly enough.Instead of registering the trace_printk() event (and other ftrace events,which are not trace events) via an early_initcall(), have them registered atthe same time that trace_printk() can be used. This way, if there is acrash before early_initcall(), then the trace_printk()s will actually beuseful.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential memory leaks in session setupMake sure to free cifs_ses::auth_key.response before allocating it aswe might end up leaking memory in reconnect or mounting.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt: Do not read past the end of test namesTest names were being concatenated based on a offset beyond the end ofthe first name, which tripped the buffer overflow detection logic: detected buffer overflow in strnlen [...] Call Trace: bnxt_ethtool_init.cold+0x18/0x18Refactor struct hwrm_selftest_qlist_output to use an actual array,and adjust the concatenation to use snprintf() rather than a series ofstrncat() calls.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: betop: check shape of output reportsbetopff_init() only checks the total sum of the report counts for eachreport field to be at least 4, but hid_betopff_play() expects 4 reportfields.A device advertising an output report with one field and 4 report countswould pass the check but crash the kernel with a NULL pointer dereferencein hid_betopff_play().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mdio: validate parameter addr in mdiobus_get_phy()The caller may pass any value as addr, what may result in an out-of-boundsaccess to array mdio_map. One existing case is stmmac_init_phy() thatmay pass -1 as addr. Therefore validate addr before using it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: close all race conditions in l2tp_tunnel_register()The code in l2tp_tunnel_register() is racy in several ways:1. It modifies the tunnel socket _after_ publishing it.2. It calls setup_udp_tunnel_sock() on an existing socket without locking.3. It changes sock lock class on fly, which triggers many syzbot reports.This patch amends all of them by moving socket initialization codebefore publishing and under sock lock. As suggested by Jakub, thel2tp lockdep class is not necessary as we can just switch tobh_lock_sock_nested().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: Fix use-after-free in local_cleanup()Fix a use-after-free that occurs in kfree_skb() called fromlocal_cleanup(). This could happen when killing nfc daemon (e.g. neard)after detaching an nfc device.When detaching an nfc device, local_cleanup() called fromnfc_llcp_unregister_device() frees local->rx_pending and decreaseslocal->ref by kref_put() in nfc_llcp_local_put().In the terminating process, nfc daemon releases all sockets and it leadsto decreasing local->ref. After the last release of local->ref,local_cleanup() called from local_release() frees local->rx_pendingagain, which leads to the bug.Setting local->rx_pending to NULL in local_cleanup() could preventuse-after-free when local_cleanup() is called twice.Found by a modified version of syzkaller.BUG: KASAN: use-after-free in kfree_skb()Call Trace:dump_stack_lvl (lib/dump_stack.c:106)print_address_description.constprop.0.cold (mm/kasan/report.c:306)kasan_check_range (mm/kasan/generic.c:189)kfree_skb (net/core/skbuff.c:955)local_cleanup (net/nfc/llcp_core.c:159)nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)nfc_llcp_local_put (net/nfc/llcp_core.c:181)llcp_sock_destruct (net/nfc/llcp_sock.c:959)__sk_destruct (net/core/sock.c:2133)sk_destruct (net/core/sock.c:2181)__sk_free (net/core/sock.c:2192)sk_free (net/core/sock.c:2203)llcp_sock_release (net/nfc/llcp_sock.c:646)__sock_release (net/socket.c:650)sock_close (net/socket.c:1365)__fput (fs/file_table.c:306)task_work_run (kernel/task_work.c:179)ptrace_notify (kernel/signal.c:2354)syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)syscall_exit_to_user_mode (kernel/entry/common.c:296)do_syscall_64 (arch/x86/entry/common.c:86)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)Allocated by task 4719:kasan_save_stack (mm/kasan/common.c:45)__kasan_slab_alloc (mm/kasan/common.c:325)slab_post_alloc_hook (mm/slab.h:766)kmem_cache_alloc_node (mm/slub.c:3497)__alloc_skb (net/core/skbuff.c:552)pn533_recv_response (drivers/nfc/pn533/usb.c:65)__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)tasklet_action_common.isra.0 (kernel/softirq.c:797)__do_softirq (kernel/softirq.c:571)Freed by task 1901:kasan_save_stack (mm/kasan/common.c:45)kasan_set_track (mm/kasan/common.c:52)kasan_save_free_info (mm/kasan/genericdd.c:518)__kasan_slab_free (mm/kasan/common.c:236)kmem_cache_free (mm/slub.c:3809)kfree_skbmem (net/core/skbuff.c:874)kfree_skb (net/core/skbuff.c:931)local_cleanup (net/nfc/llcp_core.c:159)nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)nfc_unregister_device (net/nfc/core.c:1179)pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)usb_unbind_interface (drivers/usb/core/driver.c:458)device_release_driver_internal (drivers/base/dd.c:1279)bus_remove_device (drivers/base/bus.c:529)device_del (drivers/base/core.c:3665)usb_disable_device (drivers/usb/core/message.c:1420)usb_disconnect (drivers/usb/core.c:2261)hub_event (drivers/usb/core/hub.c:5833)process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)kthread (kernel/kthread.c:319)ret_from_fork (arch/x86/entry/entry_64.S:301)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix pointer-leak due to insufficient speculative store bypass mitigationTo mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due toinsufficient speculative store bypass mitigation") inserts lfenceinstructions after 1) initializing a stack slot and 2) spilling apointer to the stack.However, this does not cover cases where a stack slot is firstinitialized with a pointer (subject to sanitization) but thenoverwritten with a scalar (not subject to sanitization becausethe slot was already initialized). In this case, the second writemay be subject to speculative store bypass (SSB) creating aspeculative pointer-as-scalar type confusion. This allows theprogram to subsequently leak the numerical pointer value using,for example, a branch-based cache side channel.To fix this, also sanitize scalars if they write a stack slotthat previously contained a pointer. Assuming that pointer-spillsare only generated by LLVM on register-pressure, the performanceimpact on most real-world BPF programs should be small.The following unprivileged BPF bytecode drafts a minimal exploitand the mitigation: [...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)SLOW: [...]After running this, the program can time the access to *(r7 + 0) todetermine whether the chosen pointer bit was 0 or 1. Repeat this 64times to recover the whole address on amd64.In summary, sanitization can only be skipped if one scalar isoverwritten with another scalar. Scalar-confusion due to speculativestore bypass can not lead to invalid accesses because the pointerbounds deducted during verification are enforced using branchlesslogic. See 979d63d50c0c ("bpf: prevent out of bounds speculation onpointer arithmetic") for details.Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks}because speculative leaks are likely unexpected if these were enabled.For example, leaking the address to a protected log file may be acceptablewhile disabling the mitigation might unintentionally leak the addressinto the cached-state of a map that is accessible to unprivilegedprocesses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/imc-pmu: Fix use of mutex in IRQs disabled sectionCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEPand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sysBelow is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1The above warning triggered because the current imc-pmu code uses mutexlock in interrupt disabled sections. The function mutex_lock()internally calls __might_resched(), which will check if IRQs aredisabled and in case IRQs are disabled, it will trigger the warning.Fix the issue by changing the mutex lock to spinlock.[mpe: Fix comments, trim oops in change log, add reported-by tags]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value ofan arithmetic expression 2 << (netmask - mask_bits - 1) is subjectto overflow due to a failure casting operands to a larger data typebefore performing the arithmetic.Note that it's harmless since the value will be checked at the next step.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm stats: check for and propagate alloc_percpu failureCheck alloc_precpu()'s return value and return an error fromdm_stats_init() if it fails. Update alloc_dev() to fail ifdm_stats_init() does.Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup()even if dm-stats isn't being actively used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_audio: don't let userspace block driver unbindIn the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()via g_audio_cleanup() will disconnect the card and then wait for allresources to be released, which happens when the refcount falls to zero.Since userspace can keep the refcount incremented by not closing therelevant file descriptor, the call to unbind may block indefinitely.This can cause a deadlock during reboot, as evidenced by the followingblocked task observed on my machine: task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ...The issue can also be observed by opening the card with arecord andthen stopping the process through the shell before unbinding: # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes)Fix the problem by using snd_card_free_when_closed() instead, which willstill disconnect the card as desired, but defer the task of freeing theresources to the core once userspace closes its file descriptor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm crypt: add cond_resched() to dmcrypt_write()The loop in dmcrypt_write may be running for unbounded amount of time,thus we need cond_resched() in it.This commit fixes the following warning:[ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]...[ 3391.387210][ C12] Call trace:[ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158[ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0[ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550[ 3391.405856][ C12] submit_bio_noacct+0x308/0x380[ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt][ 3391.416005][ C12] kthread+0x130/0x138[ 3391.419911][ C12] ret_from_fork+0x10/0x18
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Synchronize the IOCB count to be in orderA system hang was observed with the following call trace:BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022RIP: 0010:__wake_up_common+0x55/0x190Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d 40 e8 48 8d 43 08 48 89 04 24 48 89 c6\ 49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31 ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5dRSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000FS: 00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0Call Trace: __wake_up_common_lock+0x83/0xd0 qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx] __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc] nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc] nvme_fc_delete_association+0x1bf/0x220 [nvme_fc] ? nvme_remove_namespaces+0x9f/0x140 [nvme_core] nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core] nvme_sysfs_delete+0x5f/0x70 [nvme_core] kernfs_fop_write_iter+0x12b/0x1c0 vfs_write+0x2a3/0x3b0 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_loop+0xd0/0x130 ? exit_to_user_mode_prepare+0xec/0x100 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f815cd3eb97The IOCB counts are out of order and that would block any commands fromgoing out and subsequently hang the system. Synchronize the IOCB count tobe in correct order.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: revert rtnl_lock() that causes deadlockThe commit 6faee3d4ee8b ("igb: Add lock to avoid data race") addsrtnl_lock to eliminate a false data race shown below (FREE from device detaching) | (USE from netdev core)igb_remove | igb_ndo_get_vf_config igb_disable_sriov | vf >= adapter->vfs_allocated_count? kfree(adapter->vf_data) | adapter->vfs_allocated_count = 0 | | memcpy(... adapter->vf_data[vf]The above race will never happen and the extra rtnl_lock causes deadlockbelow[ 141.420169] [ 141.420672] __schedule+0x2dd/0x840[ 141.421427] schedule+0x50/0xc0[ 141.422041] schedule_preempt_disabled+0x11/0x20[ 141.422678] __mutex_lock.isra.13+0x431/0x6b0[ 141.423324] unregister_netdev+0xe/0x20[ 141.423578] igbvf_remove+0x45/0xe0 [igbvf][ 141.423791] pci_device_remove+0x36/0xb0[ 141.423990] device_release_driver_internal+0xc1/0x160[ 141.424270] pci_stop_bus_device+0x6d/0x90[ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20[ 141.424789] pci_iov_remove_virtfn+0xba/0x120[ 141.425452] sriov_disable+0x2f/0xf0[ 141.425679] igb_disable_sriov+0x4e/0x100 [igb][ 141.426353] igb_remove+0xa0/0x130 [igb][ 141.426599] pci_device_remove+0x36/0xb0[ 141.426796] device_release_driver_internal+0xc1/0x160[ 141.427060] driver_detach+0x44/0x90[ 141.427253] bus_remove_driver+0x55/0xe0[ 141.427477] pci_unregister_driver+0x2a/0xa0[ 141.428296] __x64_sys_delete_module+0x141/0x2b0[ 141.429126] ? mntput_no_expire+0x4a/0x240[ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0[ 141.429653] do_syscall_64+0x5b/0x80[ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0[ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30[ 141.430849] ? do_syscall_64+0x67/0x80[ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0[ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30[ 141.432482] ? do_syscall_64+0x67/0x80[ 141.432714] ? exc_page_fault+0x64/0x140[ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdcSince the igb_disable_sriov() will call pci_disable_sriov() beforereleasing any resources, the netdev core will synchronize the cleanup toavoid any races. This patch removes the useless rtnl_(un)lock to guaranteecorrectness.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: smsc95xx: Limit packet length to skb->lenPacket length retrieved from descriptor may be larger thanthe actual socket buffer length. In such case the clonedskb passed up the network stack will leak kernel memory contents.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_infoWe have to make sure that the info returned by the helper is validbefore using it.Found by Linux Verification Center (linuxtesting.org) with the SVACEstatic analysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: Limit packet length to skb->lenPacket length retrieved from descriptor may be larger thanthe actual socket buffer length. In such case the clonedskb passed up the network stack will leak kernel memory contents.Additionally prevent integer underflow when size is less thanETH_FCS_LEN.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix invalid address access in lookup_rec() when index is 0KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobeWhen checking pg->records[pg->index - 1].ip in lookup_rec(), it can get apg which is newly added to ftrace_pages_start in ftrace_process_locs().Before the first pg->index++, index is 0 and accessing pg->records[-1].ipwill cause this problem.Don't check the ip when pg->index is 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is notfreed, which will cause following memleak:unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30Fix the problem by freeing 'qdata' in error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix steering rules cleanupvport's mc, uc and multicast rules are not deleted in teardown path whenEEH happens. Since the vport's promisc settings(uc, mc and all) infirmware are reset after EEH, mlx5 driver will try to delete the aboverules in the initialization path. This cause kernel crash because thesesoftware rules are no longer valid.Fix by nullifying these rules right after delete to avoid accessing any danglingpointers.Call Trace:__list_del_entry_valid+0xcc/0x100 (unreliable)tree_put_node+0xf4/0x1b0 [mlx5_core]tree_remove_node+0x30/0x70 [mlx5_core]mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]esw_enable_vport+0x130/0x260 [mlx5_core]mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]mlx5_device_enable_sriov+0x74/0x440 [mlx5_core]mlx5_load_one+0x114c/0x1550 [mlx5_core]mlx5_pci_resume+0x68/0xf0 [mlx5_core]eeh_report_resume+0x1a4/0x230eeh_pe_dev_traverse+0x98/0x170eeh_handle_normal_event+0x3e4/0x640eeh_handle_event+0x4c/0x370eeh_event_handler+0x14c/0x210kthread+0x168/0x1b0ret_from_kernel_thread+0x5c/0x84
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Add missing overflow check in xdp_umem_regThe number of chunks can overflow u32. Make sure to return -EINVAL onoverflow. Also remove a redundant u32 cast assigning umem->npgs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix data corruption after failed writeWhen buffered write fails to copy data into underlying page cache page,ocfs2_write_end_nolock() just zeroes out and dirties the page. This canleave dirty page beyond EOF and if page writeback tries to write this pagebefore write succeeds and expands i_size, page gets into inconsistentstate where page dirty bit is clear but buffer dirty bits stay setresulting in page data never getting written and so data copied to thepage is lost. Fix the problem by invalidating page beyond EOF afterfailed write.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix an illegal memory accessIn the kfd_wait_on_events() function, the kfd_event_waiter structure isallocated by alloc_event_waiters(), but the event field of the waiterstructure is not initialized; When copy_from_user() fails in thekfd_wait_on_events() function, it will enter exception handling torelease the previously allocated memory of the waiter structure;Due to the event field of the waiters structure being accessedin the free_waiters() function, this results in illegal memory accessand system crash, here is the crash log:localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0localhost kernel: Call Trace:localhost kernel: _raw_spin_lock_irqsave+0x30/0x40localhost kernel: remove_wait_queue+0x12/0x50localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu]localhost kernel: ? ftrace_graph_caller+0xa0/0xa0localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu]localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu]localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu]localhost kernel: ? ftrace_graph_caller+0xa0/0xa0localhost kernel: __x64_sys_ioctl+0x8e/0xd0localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0localhost kernel: do_syscall_64+0x33/0x80localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9localhost kernel: RIP: 0033:0x152a4dff68d7Allocate the structure with kcalloc, and remove redundant 0-initializationand a redundant loop condition check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: update s_journal_inum if it changes after journal replayWhen mounting a crafted ext4 image, s_journal_inum may change after journalreplay, which is obviously unreasonable because we have successfully loadedand replayed the journal through the old s_journal_inum. And the news_journal_inum bypasses some of the checks in ext4_get_journal(), whichmay trigger a null pointer dereference problem. So if s_journal_inumchanges after the journal replay, we ignore the change, and rewrite thecurrent journal_inum to the superblock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: fsl_lpuart: fix race on RX DMA shutdownFrom time to time DMA completion can come in the middle of DMA shutdown:
: :lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free()When the timer fires a bit later, sport->dma_rx_desc is NULL:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004pc : lpuart_copy_rx_to_tty+0xcc/0x5bclr : lpuart_timer_func+0x1c/0x2cCall trace: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ...To fix this fold del_timer_sync() into lpuart_dma_rx_free() afterdmaengine_terminate_sync() to make sure timer will not be re-started inlpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave failssyzbot reported a warning[1] where the bond device itself is a slave andwe try to enslave a non-ethernet device as the first slave which failsbut then in the error path when ether_setup() restores the bond deviceit also clears all flags. In my previous fix[2] I restored theIFF_MASTER flag, but I didn't consider the case that the bond deviceitself might also be a slave with IFF_SLAVE set, so we need to restorethat flag as well. Use the bond_ether_setup helper which does the rightthing and restores the bond's flags properly.Steps to reproduce using a nlmon dev: $ ip l add nlmon0 type nlmon $ ip l add bond1 type bond $ ip l add bond2 type bond $ ip l set bond1 master bond2 $ ip l set dev nlmon0 master bond1 $ ip -d l sh dev bond1 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we try to delete it)[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef[2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")[3] example warning: [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address [ 32.464639] bond1 (unregistering): Released all slaves [ 32.464685] ------------[ cut here ]------------ [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780 [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47 [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780 [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59 [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206 [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000 [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520 [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728 [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140 [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140 [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000 [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0 [ 32.464730] Call Trace: [ 32.464763] [ 32.464767] rtnl_dellink+0x13e/0x380 [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100 [ 32.464780] ? __rtnl_unlock+0x33/0x60 [ 32.464783] ? bpf_lsm_capset+0x10/0x10 [ 32.464786] ? security_capable+0x36/0x50 [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0 [ 32.464792] ? _copy_to_iter+0xb1/0x790 [ 32.464796] ? post_alloc_hook+0xa0/0x160 [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110 [ 32.464802] netlink_rcv_skb+0x50/0xf0 [ 32.464806] netlink_unicast+0x216/0x340 [ 32.464809] netlink_sendmsg+0x23f/0x480 [ 32.464812] sock_sendmsg+0x5e/0x60 [ 32.464815] ____sys_sendmsg+0x22c/0x270 [ 32.464818] ? import_iovec+0x17/0x20 [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90 [ 32.464823] ? do_set_pte+0xa0/0xe0 [ 32.464828] ___sys_sendmsg+0x81/0xc0 [ 32.464832] ? mod_objcg_state+0xc6/0x300 [ 32.464835] ? refill_obj_stock+0xa9/0x160 [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0 [ 32.464842] __sys_sendm---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: st-nci: Fix use after free bug in ndlc_remove due to race conditionThis bug influences both st_nci_i2c_remove and st_nci_spi_remove.Take st_nci_i2c_remove as an example.In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_workwith llt_ndlc_sm_work.When it calls ndlc_recv or timeout handler, it will finally callschedule_work to start the work.When we call st_nci_i2c_remove to remove the driver, theremay be a sequence as follows:Fix it by finishing the work before cleanup in ndlc_removeCPU0 CPU1 |llt_ndlc_sm_workst_nci_i2c_remove | ndlc_remove | st_nci_remove | nci_free_device| kfree(ndev) |//free ndlc->ndev | |llt_ndlc_rcv_queue |nci_recv_frame |//use ndlc->ndev
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/iucv: Fix size of interrupt dataiucv_irq_data needs to be 4 bytes larger.These bytes are not used by the iucv module, but written bythe z/VM hypervisor in case a CPU is deconfigured.Reported as:BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten-----------------------------------------------------------------------------0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xccAllocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1__kmem_cache_alloc_node+0x166/0x450kmalloc_node_trace+0x3a/0x70iucv_cpu_prepare+0x44/0xd0cpuhp_invoke_callback+0x156/0x2f0cpuhp_issue_call+0xf0/0x298__cpuhp_setup_state_cpuslocked+0x136/0x338__cpuhp_setup_state+0xf4/0x288iucv_init+0xf4/0x280do_one_initcall+0x78/0x390do_initcalls+0x11a/0x140kernel_init_freeable+0x25e/0x2a0kernel_init+0x2e/0x170__ret_from_fork+0x3c/0x58ret_from_fork+0xa/0x40Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1__kmem_cache_free+0x308/0x358iucv_init+0x92/0x280do_one_initcall+0x78/0x390do_initcalls+0x11a/0x140kernel_init_freeable+0x25e/0x2a0kernel_init+0x2e/0x170__ret_from_fork+0x3c/0x58ret_from_fork+0xa/0x40Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0|Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZPadding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZPadding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZCPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace:[<000000032aa034ec>] dump_stack_lvl+0xac/0x100[<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140[<0000000329f5aa78>] check_object+0x370/0x3c0[<0000000329f5ede6>] free_debug_processing+0x15e/0x348[<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0[<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8[<0000000329f61768>] __kmem_cache_free+0x308/0x358[<000000032a91465c>] iucv_cpu_dead+0x6c/0x88[<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0[<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0[<0000000329c3243e>] cpu_device_down+0x4e/0x78[<000000032a61dee0>] device_offline+0xc8/0x118[<000000032a61e048>] online_store+0x60/0xe0[<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8[<0000000329fab65c>] vfs_write+0x174/0x360[<0000000329fab9fc>] ksys_write+0x74/0x100[<000000032aa03a5a>] __do_syscall+0x1da/0x208[<000000032aa177b2>] system_call+0x82/0xb0INFO: lockdep is turned off.FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xccFIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tunnels: annotate lockless accesses to dev->needed_headroomIP tunnels can apparently update dev->needed_headroomin their xmit path.This patch takes care of three tunnels xmit, and also thecore LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()helpers.More changes might be needed for completeness.BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmitread to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/i---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix kernel crash during reboot when adapter is in recovery modeIf the driver detects during probe that firmware is in recoverymode then i40e_init_recovery_mode() is called and the rest ofprobe function is skipped including pci_set_drvdata(). Subsequenti40e_shutdown() called during shutdown/reboot dereferences NULLpointer as pci_get_drvdata() returns NULL.To fix call pci_set_drvdata() also during entering to recovery mode.Reproducer:1) Lets have i40e NIC with firmware in recovery mode2) Run rebootResult:[ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver[ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.[ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.[ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.[ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a][ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0[ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.[ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.[ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a][ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0...[ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2[ 156.318330] #PF: supervisor write access in kernel mode[ 156.323546] #PF: error_code(0x0002) - not-present page[ 156.328679] PGD 0 P4D 0[ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI[ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1[ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022[ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e][ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00[ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282[ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001[ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000[ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40[ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000[ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000[ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000[ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0[ 156.438944] PKRU: 55555554[ 156.441647] Call Trace:[ 156.444096] [ 156.446199] pci_device_shutdown+0x38/0x60[ 156.450297] device_shutdown+0x163/0x210[ 156.454215] kernel_restart+0x12/0x70[ 156.457872] __do_sys_reboot+0x1ab/0x230[ 156.461789] ? vfs_writev+0xa6/0x1a0[ 156.465362] ? __pfx_file_free_rcu+0x10/0x10[ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0[ 156.475034] do_syscall_64+0x3e/0x90[ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc[ 156.483658] RIP: 0033:0x7fe7bff37ab7
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: prevent out-of-bounds array speculation when closing a file descriptorGoogle-Bug-Id: 114199369
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix a procfs host directory removal regressionscsi_proc_hostdir_rm() decreases a reference counter and hence must only becalled once per host that is removed. This change does not require ascsi_add_host_with_dma() change since scsi_add_host_with_dma() will return0 (success) if scsi_proc_host_add() is called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: initialize struct pn533_out_arg properlystruct pn533_out_arg used as a temporary context for out_urb is notinitialized properly. Its uninitialized 'phy' field can be dereferenced inerror cases inside pn533_out_complete() callback function. It causes thefollowing failure:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441Call Trace: __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671 usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754 dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700 expire_timers+0x234/0x330 kernel/time/timer.c:1751 __run_timers kernel/time/timer.c:2022 [inline] __run_timers kernel/time/timer.c:1995 [inline] run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035 __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x9/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107Initialize the field with the pn533_usb_phy currently used.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_make_synack() can be called from process contexttcp_rtx_synack() now could be called in process context as explained in0a375c822497 ("tcp: tcp_rtx_synack() can be called from processcontext").tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPUvariables with preemption enabled. This causes the following BUG: BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464 caller is tcp_make_synack+0x841/0xac0 Call Trace: dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. UseTCP_INC_STATS() which is safe to be called from context switch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add()Port is allocated by sas_port_alloc_num() and rphy is allocated by eithersas_end_device_alloc() or sas_expander_alloc(), all of which may returnNULL. So we need to check the rphy to avoid possible NULL pointer access.If sas_rphy_add() returned with failure, rphy is set to NULL. We wouldaccess the rphy in the following lines which would also result NULL pointeraccess.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: smsc75xx: Limit packet length to skb->lenPacket length retrieved from skb data may be larger thanthe actual socket buffer length (up to 9026 bytes). In suchcase the cloned skb passed up the network stack will leakkernel memory contents.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix a server shutdown leakFix a race where kthread_stop() may prevent the threadfn from ever gettingcalled. If that happens the svc_rqst will not be cleaned up.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()When the buffer length of the recvmsg system call is 0, we got theflollowing soft lockup problem:watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:remove_wait_queue+0xb/0xc0Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThe logic in tcp_bpf_recvmsg_parser is as follows:msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; }In this case, "copied" always is 0, the infinite loop occurs.According to the Linux system call man page, 0 should be returned in thiscase. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directlyreturn. Also modify several other functions with the same problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_propertiesdevm_kmalloc_array may fails, *fw_vsc_cfg might be null and causeout-of-bounds write in device_property_read_u8_array later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Remove the /proc/scsi/${proc_name} directory earlierRemove the /proc/scsi/${proc_name} directory earlier to fix a racecondition between unloading and reloading kernel modules. This fixes a bugintroduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak inthe SCSI core").Fix the following kernel warning:proc_dir_entry 'scsi/scsi_debug' already registeredWARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0Call Trace: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()ila_xlat_nl_cmd_get_mapping() generates an empty skb,triggerring a recent sanity check [1].Instead, return an error code, so that user spacecan get it.[1]skb_assert_lenWARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156Modules linked in:CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_assert_len include/linux/skbuff.h:2527 [inline]pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156lr : skb_assert_len include/linux/skbuff.h:2527 [inline]lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156sp : ffff80001e0d6c40x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000eCall trace:skb_assert_len include/linux/skbuff.h:2527 [inline]__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156dev_queue_xmit include/linux/netdevice.h:3033 [inline]__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380nlmsg_unicast include/net/netlink.h:1099 [inline]genlmsg_unicast include/net/genetlink.h:433 [inline]genlmsg_reply include/net/genetlink.h:443 [inline]ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:714 [inline]sock_sendmsg net/socket.c:734 [inline]____sys_sendmsg+0x558/0x844 net/socket.c:2479___sys_sendmsg net/socket.c:2533 [inline]__sys_sendmsg+0x26c/0x33c net/socket.c:2562__do_sys_sendmsg net/socket.c:2571 [inline]__se_sys_sendmsg net/socket.c:2569 [inline]__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591irq event stamp: 136484hardirqs last enabled at (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345hardirqs last disabled at (136484): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405softirqs last enabled at (136418): [] softirq_ha---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: add NULL check in xfrm_update_ae_paramsNormally, x->replay_esn and x->preplay_esn should be allocated atxfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence thexfrm_update_ae_params(...) is okay to update them. However, the currentimplementation of xfrm_new_ae(...) allows a malicious user to directlydereference a NULL pointer and crash the kernel like below.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0Oops: 0002 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4RIP: 0010:memcpy_orig+0xad/0x140Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 cRSP: 0018:ffff888008f57658 EFLAGS: 00000202RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x1e8/0x500 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? fixup_exception+0x36/0x460 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? exc_page_fault+0x5e/0xc0 ? asm_exc_page_fault+0x26/0x30 ? xfrm_update_ae_params+0xd1/0x260 ? memcpy_orig+0xad/0x140 ? __pfx__raw_spin_lock_bh+0x10/0x10 xfrm_update_ae_params+0xe7/0x260 xfrm_new_ae+0x298/0x4e0 ? __pfx_xfrm_new_ae+0x10/0x10 ? __pfx_xfrm_new_ae+0x10/0x10 xfrm_user_rcv_msg+0x25a/0x410 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __alloc_skb+0xcf/0x210 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1c/0x70 ? __stack_depot_save+0x39/0x4e0 ? __kasan_slab_free+0x10a/0x190 ? kmem_cache_free+0x9c/0x340 ? netlink_recvmsg+0x23c/0x660 ? sock_recvmsg+0xeb/0xf0 ? __sys_recvfrom+0x13c/0x1f0 ? __x64_sys_recvfrom+0x71/0x90 ? do_syscall_64+0x3f/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc ? copyout+0x3e/0x50 netlink_rcv_skb+0xd6/0x210 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_sock_has_perm+0x10/0x10 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 xfrm_netlink_rcv+0x44/0x50 netlink_unicast+0x36f/0x4c0 ? __pfx_netlink_unicast+0x10/0x10 ? netlink_recvmsg+0x500/0x660 netlink_sendmsg+0x3b7/0x700This Null-ptr-deref bug is assigned CVE-2023-3772. And this commitadds additional NULL check in xfrm_update_ae_params to fix the NPD.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid deadlock in fs reclaim with page writebackExt4 has a filesystem wide lock protecting ext4_writepages() calls toavoid races with switching of journalled data flag or inode format. Thislock can however cause a deadlock like:CPU0 CPU1ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks foreverMake sure we cannot recurse into filesystem reclaim from writeback codeto avoid the deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Pointer may be dereferencedKlocwork tool reported pointer 'rport' returned from call to functionfc_bsg_to_rport() may be NULL and will be dereferenced.Add a fix to validate rport before dereferencing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: prevent soft lockup while flush writesCurrently, there is no limit for raid1/raid10 plugged bio. While flushingwrites, raid1 has cond_resched() while raid10 doesn't, and too manywrites can cause soft lockup.Follow up soft lockup can be triggered easily with writeback test forraid10 with ramdisks:watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]Call Trace: call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0Fix the problem by adding cond_resched() to raid10 like what raid1 did.Note that unlimited plugged bio still need to be optimized, for example,in the case of lots of dirty pages writeback, this will take lots ofmemory and io will spend a long time in plug, hence io latency is bad.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Fix use after free for wextKey information in wext.connect is not reset on (re)connect and can holddata from a previous connection.Reset key data to avoid that drivers or mac80211 incorrectly detect aWEP connection request and access the freed or already reused memory.Additionally optimize cfg80211_sme_connect() and avoid an uselessschedule of conn_work.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix possible memory leak if device_add() failsIf device_add() returns error, the name allocated by dev_set_name() needsbe freed. As the comment of device_add() says, put_device() should be usedto decrease the reference count in the error path. So fix this by callingput_device(), then the name can be freed in kobject_cleanp().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix zswap writeback race conditionThe zswap writeback mechanism can cause a race condition resulting inmemory corruption, where a swapped out page gets swapped in with data thatwas written to a different page.The race unfolds like this:1. a page with data A and swap offset X is stored in zswap2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver3. user space program faults and invalidates page entry A, offset X is considered free4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.)5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work6. zswap-shrink work writes back A at X, and frees zswap entry A7. swapin of slot X brings A in memory instead of BThe fix:Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),zswap-shrink work just checks that the local zswap_entry reference isstill the same as the one in the tree. If it's not the same it means thatit's either been invalidated or replaced, in both cases the writeback isaborted because the local entry contains stale data.Reproducer:I originally found this by running `stress` overnight to validate my workon the zswap writeback mechanism, it manifested after hours on my testmachine. The key to make it happen is having zswap writebacks, sowhatever setup pumps /sys/kernel/debug/zswap/written_back_pages should dothe trick.In order to reproduce this faster on a vm, I setup a system with ~100M ofavailable memory and a 500M swap file, then running `stress --vm 1--vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tensof minutes. One can speed things up even more by swinging/sys/module/zswap/parameters/max_pool_percent up and down between, say, 20and 1; this makes it reproduce in tens of seconds. It's crucial to set`--vm-stride` to something other than 4096 otherwise `stress` won'trealize that memory has been corrupted because all pages would have thesame data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: don't allow to overwrite ENDPOINT0 attributesA bad USB device is able to construct a service connection responsemessage with target endpoint being ENDPOINT0 which is reserved forHTC_CTRL_RSVD_SVC and should not be modified to be used for any otherservices.Reject such service connection responses.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix race on port outputassume the following setup on a single machine:1. An openvswitch instance with one bridge and default flows2. two network namespaces "server" and "client"3. two ovs interfaces "server" and "client" on the bridge4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues5. move the ends of the veth pairs to the respective network namespaces6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)7. start some http server on the server network namespace8. test if a client in the client namespace can reach the http serverwhen following the actions below the host has a chance of getting a cpustuck in a infinite loop:1. send a large amount of parallel requests to the http server (around 3000 curls should work)2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)there is a low chance that this will cause the below kernel cpu stuckmessage. If this does not happen just retry.Below there is also the output of bpftrace for the functions mentionedin the output.The series of events happening here is:1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net`3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs)5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 08. port deletion continues (but details are not relevant for this issue)9. at some future point the background task deletes the vportIf after 7. but before 9. a packet is send to the ovs vport (which isnot deleted at this point in time) which forwards it to the`dev_queue_xmit` flow even though the device is unregistering.In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there isa while loop (if the packet has a rx_queue recorded) that is infinite if`dev->real_num_tx_queues` is zero.To prevent this from happening we update `do_output` to handle deviceswithout carrier the same as if the device is not found (which wouldbe the code path after 9. is done).Additionally we now produce a warning in `skb_tx_hash` if we will hitthe infinite loop.bpftrace (first word is function name):__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2dp_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/addrconf: fix a potential refcount underflow for idevNow in addrconf_mod_rs_timer(), reference idev depends on whetherrs_timer is not pending. Then modify rs_timer timeout.There is a time gap in [1], during which if the pending rs_timerbecomes not pending. It will miss to hold idev, but the rs_timeris activated. Thus rs_timer callback function addrconf_rs_timer()will be executed and put idev later without holding idev. A refcountunderflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when);To fix the issue, hold idev if mod_timer() return 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domainsof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() failsSyzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream().While processing skbs in ath9k_hif_usb_rx_stream(), the already allocatedskbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If wehave an incorrect pkt_len or pkt_tag, the input skb is considered invalidand dropped. All the associated packets already in skb_pool should bedropped and freed. Added a comment describing this issue.The patch also makes remain_skb NULL after being processed so that itcannot be referenced after potential free. The initialization of hif_devfields which are associated with remain_skb (rx_remain_len,rx_transfer_len and rx_pad_len) is moved after a new remain_skb isallocated.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: wraparound mbox producer indexDriver is not handling the wraparound of the mbox producer index correctly.Currently the wraparound happens once u32 max is reached.Bit 31 of the producer index register is special and should be setonly once for the first command. Because the producer index overflowsetting bit31 after a long time, FW goes to initialization sequenceand this causes FW hang.Fix is to wraparound the mbox producer index once it reaches u16 max.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-races around user->unix_inflight.user->unix_inflight is changed under spin_lock(unix_gc_lock),but too_many_unix_fds() reads it locklessly.Let's annotate the write/read accesses to user->unix_inflight.BUG: KCSAN: data-race in unix_attach_fds / unix_inflightwrite to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8value changed: 0x000000000000000c -> 0x000000000000000dReported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()Fix a slab-out-of-bounds read that occurs in kmemdup() called frombrcmf_get_assoc_ies().The bug could occur when assoc_info->req_len, data from a URB providedby a USB device, is bigger than the size of buffer which is defined asWL_EXTRA_BUF_MAX.Add the size check for req_len/resp_len of assoc_info.Found by a modified version of syzkaller.[ 46.592467][ T7] ==================================================================[ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50[ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7[ 46.598575][ T7][ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145[ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014[ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker[ 46.605943][ T7] Call Trace:[ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1[ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334[ 46.608610][ T7] ? kmemdup+0x3e/0x50[ 46.609341][ T7] kasan_report.cold+0x79/0xd5[ 46.610151][ T7] ? kmemdup+0x3e/0x50[ 46.610796][ T7] kasan_check_range+0x14e/0x1b0[ 46.611691][ T7] memcpy+0x20/0x60[ 46.612323][ T7] kmemdup+0x3e/0x50[ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60[ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0[ 46.614831][ T7] ? lock_chain_count+0x20/0x20[ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770[ 46.616552][ T7] ? lock_chain_count+0x20/0x20[ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770[ 46.618244][ T7] ? lock_chain_count+0x20/0x20[ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0[ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0[ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790[ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950[ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0[ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0[ 46.623390][ T7] ? find_held_lock+0x2d/0x110[ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60[ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0[ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0[ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0[ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100[ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60[ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100[ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0[ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0[ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0[ 46.630649][ T7] process_one_work+0x92b/0x1460[ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330[ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90[ 46.632347][ T7] worker_thread+0x95/0xe00[ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0[ 46.633393][ T7] ? process_one_work+0x1460/0x1460[ 46.633957][ T7] kthread+0x3a1/0x480[ 46.634369][ T7] ? set_kthread_struct+0x120/0x120[ 46.634933][ T7] ret_from_fork+0x1f/0x30[ 46.635431][ T7][ 46.635687][ T7] Allocated by task 7:[ 46.636151][ T7] kasan_save_stack+0x1b/0x40[ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90[ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330[ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040[ 46.638275][ T7] brcmf_attach+0x389/0xd40[ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690[ 46.639279][ T7] usb_probe_interface+0x2aa/0x760[ 46.639820][ T7] really_probe+0x205/0xb70[ 46.640342][ T7] __driver_probe_device+0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Fix OOB and integer underflow when rx packetsMake sure mwifiex_process_mgmt_packet,mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packetnot out-of-bounds access the skb->data buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded staAvoid potential data corruption issues caused by uninitialized driverprivate data structures.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: storvsc: Fix handling of virtual Fibre Channel timeoutsHyper-V provides the ability to connect Fibre Channel LUNs to the hostsystem and present them in a guest VM as a SCSI device. I/O to the vFCdevice is handled by the storvsc driver. The storvsc driver includes apartial integration with the FC transport implemented in the genericportion of the Linux SCSI subsystem so that FC attributes can be displayedin /sys. However, the partial integration means that some aspects of vFCdon't work properly. Unfortunately, a full and correct integration isn'tpractical because of limitations in what Hyper-V provides to the guest.In particular, in the context of Hyper-V storvsc, the FC transport timeoutfunction fc_eh_timed_out() causes a kernel panic because it can't find therport and dereferences a NULL pointer. The original patch that added thecall from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in thisregard.In many cases a timeout is due to a transient condition, so the situationcan be improved by just continuing to wait like with other I/O requestsissued by storvsc, and avoiding the guaranteed panic. For a permanentfailure, continuing to wait may result in a hung thread instead of a panic,which again may be better.So fix the panic by removing the storvsc call to fc_eh_timed_out(). Thisallows storvsc to keep waiting for a response. The change has been testedby users who experienced a panic in fc_eh_timed_out() due to transienttimeouts, and it solves their problem.In the future we may want to deprecate the vFC functionality in storvscsince it can't be fully fixed. But it has current users for whom it isworking well enough, so it should probably stay for a while longer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALLWhen compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automountis NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes toS_AUTOMOUNT and corresponding dentry flags is retained regardless ofCONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference inVFS follow_automount() when traversing a DFS referral link: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: __traverse_mounts+0xb5/0x220 ? cifs_revalidate_mapping+0x65/0xc0 [cifs] step_into+0x195/0x610 ? lookup_fast+0xe2/0xf0 path_lookupat+0x64/0x140 filename_lookup+0xc2/0x140 ? __create_object+0x299/0x380 ? kmem_cache_alloc+0x119/0x220 ? user_path_at_empty+0x31/0x50 user_path_at_empty+0x31/0x50 __x64_sys_chdir+0x2a/0xd0 ? exit_to_user_mode_prepare+0xca/0x100 do_syscall_64+0x42/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThis fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handlerwhen CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be toavoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. Thisapproach was chosen as it provides more control over the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: install stub fence into potential unused fence pointersWhen using cpu to update page tables, vm update fences are unused.Install stub fence into these fence pointers instead of NULLto avoid NULL dereference when calling dma_fence_wait() on them.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handleKASAN reported a null-ptr-deref error:KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 1373 Comm: modprobeHardware name: QEMU Standard PC (i440FX + PIIX, 1996)RIP: 0010:dmi_sysfs_entry_release...Call Trace: kobject_put dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs dmi_decode_table (drivers/firmware/dmi_scan.c:133) dmi_walk (drivers/firmware/dmi_scan.c:1115) dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs do_one_initcall (init/main.c:1296) ...Kernel panic - not syncing: Fatal exceptionKernel Offset: 0x4000000 from 0xffffffff81000000---[ end Kernel panic - not syncing: Fatal exception ]---It is because previous patch added kobject_put() to release the memorywhich will call dmi_sysfs_entry_release() and list_del().However, list_add_tail(entry->list) is called after the error block,so the list_head is uninitialized and cannot be deleted.Move error handling to after list_add_tail to fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPFThe call to get_user_pages_fast() in vmci_host_setup_notify() can returnNULL context->notify_page causing a GPF. To avoid GPF check ifcontext->notify_page == NULL and return error if so.general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307]CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0Call Trace: vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: ensure that VID header offset + VID header size <= alloc, sizeEnsure that the VID header offset + VID header size does not exceedthe allocated area to avoid slab OOB.BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W6.0.0-1868 #1Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d2904/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0RIP: 0033:0x7f96d5cf753dCode:RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753dRDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0The buggy address belongs to the object at ffff88802bb36e00 which belongs to the cache kmalloc-256 of size 256The buggy address is located 0 bytes to the right of 256-byte region [ffff88802bb36e00, ffff88802bb36f00)The buggy address belongs to the physical page:page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000index:0x0 pfn:0x2bb36head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40raw: 0000000000000000 00000000001---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwl3945: Add missing check for create_singlethread_workqueueAdd the check for the return value of the create_singlethread_workqueuein order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/client: Fix memory leak in drm_client_modeset_probeWhen a new mode is set to modeset->mode, the previous mode should be freed.This fixes the following kmemleak report:drm_mode_duplicate+0x45/0x220 [drm]drm_client_modeset_probe+0x944/0xf50 [drm]__drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]drm_client_register+0x169/0x240 [drm]ast_pci_probe+0x142/0x190 [ast]local_pci_probe+0xdc/0x180work_for_cpu_fn+0x4e/0xa0process_one_work+0x8b7/0x1540worker_thread+0x70a/0xed0kthread+0x29f/0x340ret_from_fork+0x1f/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: bdisp: Add missing check for create_workqueueAdd the check for the return value of the create_workqueuein order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix leak of 'r10bio->remaining' for recoveryraid10_sync_request() will add 'r10bio->remaining' for both rdev andreplacement rdev. However, if the read io fails, recovery_request_write()returns without issuing the write io, in this case, end_sync_request()is only called once and 'remaining' is leaked, cause an io hang.Fix the problem by decreasing 'remaining' according to if 'bio' and'repl_bio' is valid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwl4965: Add missing check for create_singlethread_workqueue()Add the check for the return value of the create_singlethread_workqueue()in order to avoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix use-after-freeFix potential use-after-free in l2cap_le_command_rej.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() failsIf getting an ID or setting up a work queue in rbd_dev_create() fails,use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->optsis triggered in do_rbd_add(). The root cause is that the ownership ofthese structures is transfered to rbd_dev prematurely and they all endup getting freed when rbd_dev_create() calls rbd_dev_free() prior toreturning to do_rbd_add().Found by Linux Verification Center (linuxtesting.org) with SVACE, anincomplete patch submitted by Natalia Petrova .
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Better handle pm_runtime_get() failing in .remove()In the (unlikely) event that pm_runtime_get() (disguised aspm_runtime_resume_and_get()) fails, the remove callback returned anerror early. The problem with this is that the driver core ignores theerror value and continues removing the device. This results in aresource leak. Worse the devm allocated resources are freed and so if acallback of the driver is called later the register mapping is alreadygone which probably results in a crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix integer overflow in radeon_cs_parser_initThe type of size is unsigned, if size is 0x40000000, there will be aninteger overflow, size will be zero after size *= sizeof(uint32_t),will cause uninitialized memory to be referenced later
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix wrong setting of max_corr_read_errorsThere is no input check when echo md/max_read_errors and overflow mightoccur. Add check of input number.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc: Don't try to copy PPR for task with NULL pt_regspowerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, whichfrom my (arguably very short) checking is not commonly done for otherarchs. This is fine, except when PF_IO_WORKER's have been created andthe task does something that causes a coredump to be generated. Then weget this crash: Kernel attempted to read user page (160) - exploit attempt? (uid: 1000) BUG: Kernel NULL pointer dereference on read at 0x00000160 Faulting instruction address: 0xc0000000000c3a60 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0 REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+) MSR: 800000000280b033 CR: 88082828 XER: 200400f8 ... NIP memcpy_power7+0x200/0x7d0 LR ppr_get+0x64/0xb0 Call Trace: ppr_get+0x40/0xb0 (unreliable) __regset_get+0x180/0x1f0 regset_get_alloc+0x64/0x90 elf_core_dump+0xb98/0x1b60 do_coredump+0x1c34/0x24a0 get_signal+0x71c/0x1410 do_notify_resume+0x140/0x6f0 interrupt_exit_user_prepare_main+0x29c/0x320 interrupt_exit_user_prepare+0x6c/0xa0 interrupt_return_srr_user+0x8/0x138Because ppr_get() is trying to copy from a PF_IO_WORKER with a NULLpt_regs.Check for a valid pt_regs in both ppc_get/ppr_set, and return an errorif not set. The actual error value doesn't seem to be important here, sojust pick -EINVAL.[mpe: Trim oops in change log, add Fixes & Cc stable]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pstore/ram: Check start of empty przs during initAfter commit 30696378f68a ("pstore/ram: Do not treat empty buffers asvalid"), initialization would assume a prz was valid after seeing thatthe buffer_size is zero (regardless of the buffer start position). Thisunchecked start value means it could be outside the bounds of the buffer,leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ...To avoid this, also check if the prz start is 0 during the initializationphase. If not, the next prz sanity check case will discover it (start >size) and zap the buffer back to a sane state.[kees: update commit log with backtrace and clarifications]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()If ipi_send_{mask|single}() is called with an invalid interrupt number, allthe local variables there will be NULL. ipi_send_verify() which is invokedfrom these functions does verify its 'data' parameter, resulting in akernel oops in irq_data_get_affinity_mask() as the passed NULL pointer getsdereferenced.Add a missing NULL pointer check in ipi_send_verify()...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic oneEric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is 'pulled' from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x ...) So dccp_ack_seq() is happily reading stuff past the _dh buffer.BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371[..]Fix this by increasing the stack buffer to also include room forthe extra sequence numbers and all the known dccp packet type headers,then pull again after the initial validation of the basic header.While at it, mark packets invalid that lack 48bit sequence bit butwhere RFC says the type MUST use them.Compile tested only.v2: first skb_header_pointer() now needs to adjust the size to only pull the generic header. (Eric)Heads-up: I intend to remove dccp conntrack support later this year.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()If get_ep_from_tid() fails to lookup non-NULL value for ep, ep isdereferenced later regardless of whether it is empty.This patch adds a simple sanity check to fix the issue.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix BUG_ON condition in btrfs_cancel_balancePausing and canceling balance can race to interrupt balance lead to BUG_ONpanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balancedoes not take this race scenario into account.However, the race condition has no other side effects. We can fix that.Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_writeSyzkaller reported the following issue:=====================================================BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600 aio_rw_done fs/aio.c:1520 [inline] aio_write+0x899/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc+0x11d/0x3b0 mm/slab_common.c:981 kmalloc_array include/linux/slab.h:636 [inline] bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930 bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] sock_write_iter+0x495/0x5e0 net/socket.c:1108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdCPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023=====================================================We can follow the call chain and find that 'bcm_tx_setup' functioncalls 'memcpy_from_msg' to copy some content to the newly allocatedframe of 'op->frames'. After that the 'len' field of copied structurebeing compared with some constant value (64 or 8). However, if'memcpy_from_msg' returns an error, we will compare some uninitializedmemory. This triggers 'uninit-value' issue.This patch will add 'memcpy_from_msg' possible errors processing toavoid uninit-value issue.Tested via syzkaller
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock when aborting transaction during relocation with scrubBefore relocating a block group we pause scrub, then do the relocation andthen unpause scrub. The relocation process requires starting and committinga transaction, and if we have a failure in the critical section of thetransaction commit path (transaction state >= TRANS_STATE_COMMIT_START),we will deadlock if there is a paused scrub.That results in stack traces like the following: [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6 [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction. [42.936] ------------[ cut here ]------------ [42.936] BTRFS: Transaction aborted (error -28) [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...) [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Code: ff ff 45 8b (...) [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282 [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000 [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8 [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00 [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0 [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000 [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0 [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42.936] Call Trace: [42.936] [42.936] ? start_transaction+0xcb/0x610 [btrfs] [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs] [42.936] relocate_block_group+0x57/0x5d0 [btrfs] [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs] [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs] [42.936] ? __pfx_autoremove_wake_function+0x10/0x10 [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs] [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs] [42.936] ? __kmem_cache_alloc_node+0x14a/0x410 [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs] [42.937] ? mod_objcg_state+0xd2/0x360 [42.937] ? refill_obj_stock+0xb0/0x160 [42.937] ? seq_release+0x25/0x30 [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0 [42.937] ? percpu_counter_add_batch+0x2e/0xa0 [42.937] ? __x64_sys_ioctl+0x88/0xc0 [42.937] __x64_sys_ioctl+0x88/0xc0 [42.937] do_syscall_64+0x38/0x90 [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc [42.937] RIP: 0033:0x7f381a6ffe9b [42.937] Code: 00 48 89 44 24 (...) [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003 [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000 [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423 [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148 [42.937] [42.937] ---[ end trace 0000000000000000 ]--- [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds. [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [59.196] "echo 0 > /proc/sys/kernel/hung_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6mr: Fix skb_under_panic in ip6mr_cache_report()skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x152/0x1d0 Call Trace: skb_push+0xc4/0xe0 ip6mr_cache_report+0xd69/0x19b0 reg_vif_xmit+0x406/0x690 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 vlan_dev_hard_start_xmit+0x3ab/0x5c0 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 neigh_connected_output+0x3ed/0x570 ip6_finish_output2+0x5b5/0x1950 ip6_finish_output+0x693/0x11c0 ip6_output+0x24b/0x880 NF_HOOK.constprop.0+0xfd/0x530 ndisc_send_skb+0x9db/0x1400 ndisc_send_rs+0x12a/0x6c0 addrconf_dad_completed+0x3c9/0xea0 addrconf_dad_work+0x849/0x1420 process_one_work+0xa22/0x16e0 worker_thread+0x679/0x10c0 ret_from_fork+0x28/0x60 ret_from_fork_asm+0x11/0x20When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().reg_vif_xmit() ip6mr_cache_report() skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4And skb_push declared as: void *skb_push(struct sk_buff *skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race issue between cpu buffer write and swapWarning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142 rb_commit+0x402/0x4a0 Call Trace: ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_event_sched_switch+0x23c/0x2c0 __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0It is because the race between writing event into cpu buffer and swappingcpu buffer through file per_cpu/cpu0/snapshot: Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1 -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b; buffer_b->buffers[cpu] = cpu_buffer_a; // 2. cpu_buffer has swapped here. rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer' [...] // has not changed here. return NULL; } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. Reserve event from 'cpu_buffer_a'. ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!! rb_commit(cpu_buffer) rb_end_commit() // 6. WARN for the wrong 'committing' state !!!Based on above analysis, we can easily reproduce by following testcase: ``` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR}/buffer_size_kb echo "sched:sched_switch" > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & ```To fix it, IIUC, we can use smp_call_function_single() to do the swap onthe target cpu where the buffer is located, so that above race would beavoided.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dcb: choose correct policy to parse DCB_ATTR_BCNThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],which is introduced in commit 859ee3c43812 ("DCB: Add support for DCBBCN"). Please see the comment in below codestatic int dcbnl_bcn_setcfg(...){ ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ...}That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nestattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But thefollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.By looking up the associated nla_policy for dcbnl_bcn_attrs. We can findthe beginning part of these two policies are "same".static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},};static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},};Therefore, the current code is buggy and thisnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and usethe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.Hence use the correct policy dcbnl_bcn_nest to parse the nestedtb[DCB_ATTR_BCN] TLV.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Handle EBUSY correctlyAs it is seqiv only handles the special return value of EINPROGERSS,which means that in all other cases it will free data related to therequest.However, as the caller of seqiv may specify MAY_BACKLOG, we also needto expect EBUSY and treat it in the same way. Otherwise backloggedrequests will trigger a use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: fix null-ptr-deref of mreplace in raid10_sync_requestThere are two check of 'mreplace' in raid10_sync_request(). In the firstcheck, 'need_replace' will be set and 'mreplace' will be used later ifno-Faulty 'mreplace' exists, In the second check, 'mreplace' will beset to NULL if it is Faulty, but 'need_replace' will not be changedaccordingly. null-ptr-deref occurs if Faulty is set between two check.Fix it by merging two checks into one. And replace 'need_replace' with'mreplace' because their values are always the same.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: avoid possible NULL skb pointer dereferenceIn 'mwifiex_handle_uap_rx_forward()', always check the valuereturned by 'skb_copy()' to avoid potential NULL pointerdereference in 'mwifiex_uap_queue_bridged_pkt()', and droporiginal skb in case of copying failure.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfsAs the ramfs-based tmpfs uses ramfs_init_fs_context() for theinit_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb()to free it and avoid a memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for deviceCurrently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),there is a special handling in order to use the correct counters, but,port_num is being passed down the stack without any change. Also, somefunctions assume that port_num >=1. As a result, the following oops canoccur. BUG: unable to handle page fault for address: ffff89510294f1a8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock+0xc/0x20 Call Trace: mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib] do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib] mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib] ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510 [ib_core] ? atomic_notifier_chain_register+0x67/0x80 __mlx5_ib_add+0x2b/0x80 [mlx5_ib] mlx5r_probe+0xb8/0x150 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x3c/0x70 ? driver_sysfs_add+0x6b/0x90 really_probe+0xcd/0x380 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 ? driver_allows_async_probing+0x60/0x60 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x7b/0xc0 __device_attach+0xbc/0x200 bus_probe_device+0x87/0xa0 device_add+0x404/0x940 ? dev_set_name+0x53/0x70 __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc8/0x120 [mlx5_core] mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core] devlink_reload+0x133/0x250 devlink_nl_cmd_reload+0x480/0x570 ? devlink_nl_pre_doit+0x44/0x2b0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x180/0x2b0 ? devlink_nl_cmd_region_read_dumpit+0x540/0x540 ? devlink_reload+0x250/0x250 ? devlink_put+0x50/0x50 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x1c0/0x5f0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0Fix it by setting port_num to 1 in order to get device status and removeunused variable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:modpost: fix off by one in is_executable_section()The > comparison should be >= to prevent an out of bounds arrayaccess.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix Oops by 9.1 surround channel namesget_line_out_pfx() may trigger an Oops by overflowing the static arraywith more than 8 channels. This was reported for MacBookPro 12,1 withCirrus codec.As a workaround, extend for the 9.1 channels and also fix thepotential Oops by unifying the code paths accessing the same arraywith the proper size check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix warning and UAF when destroy the MR listIf the MR allocate failed, the MR recovery work not initializedand list not cleared. Then will be warning and UAF when releasethe MR: WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110 CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82 RIP: 0010:__flush_work.isra.0+0xf7/0x110 Call Trace: __cancel_work_timer+0x2ba/0x2e0 smbd_destroy+0x4e1/0x990 _smbd_get_connection+0x1cbd/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990 Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824 CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82 Call Trace: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 smbd_destroy+0x4fc/0x990 _smbd_get_connection+0x1cbd/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Allocated by task 824: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7a/0x90 _smbd_get_connection+0x1b6f/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 824: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 __kmem_cache_free+0xc8/0x330 _smbd_get_connection+0x1c6a/0x2110 smbd_get_connection+0x21/0x40 cifs_get_tcp_session+0x8ef/0xda0 mount_get_conns+0x60/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0Let's initialize the MR recovery work before MR allocate to preventthe warning, remove the MRs from the list to prevent the UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add vlan_get_protocol_and_depth() helperBefore blamed commit, pskb_may_pull() was used insteadof skb_header_pointer() in __vlan_get_protocol() and friends.Few callers depended on skb->head being populated with MAC header,syzbot caught one of them (skb_mac_gso_segment())Add vlan_get_protocol_and_depth() to make the intent clearerand use it where sensible.This is a more generic fix than commit e9d3f80935b6("net/af_packet: make sure to pull mac header") which wasdealing with a similar issue.kernel BUG at include/linux/skbuff.h:2655 !invalid opcode: 0000 [#1] SMP KASANCPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419[] skb_gso_segment include/linux/netdevice.h:4819 [inline][] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725[] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313[] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029[] packet_snd net/packet/af_packet.c:3111 [inline][] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: snic: Fix possible memory leak if device_add() failsIf device_add() returns error, the name allocated by dev_set_name() needsbe freed. As the comment of device_add() says, put_device() should be usedto give up the reference in the error path. So fix this by callingput_device(), then the name can be freed in kobject_cleanp().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: cpumap: Fix memory leak in cpu_map_update_elemSyzkaller reported a memory leak as follows:BUG: memory leakunreferenced object 0xff110001198ef748 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J........... 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(....... backtrace: [] __cpu_map_entry_alloc+0xf7/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff110001198ef528 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __cpu_map_entry_alloc+0x260/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff1100010fd93d68 (size 8): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [] kvmalloc_node+0x11e/0x170 [] __cpu_map_entry_alloc+0x2f0/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6In the cpu_map_update_elem flow, when kthread_stop is called beforecalling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bitof kthread has been set by kthread_stop, the threadfn of rcpu->kthreadwill never be executed, and rcpu->refcnt will never be 0, which willlead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot bereleased.Calling kthread_stop before executing kthread's threadfn will return-EINTR. We can complete the release of memory resources in this state.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-freeStruct pcie_link_state->downstream is a pointer to the pci_dev of function0. Previously we retained that pointer when removing function 0, andsubsequent ASPM policy changes dereferenced it, resulting in ause-after-free warning from KASAN, e.g.: # echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove # echo powersave > /sys/module/pcie_aspm/parameters/policy BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500 Call Trace: kasan_report+0xae/0xe0 pcie_config_aspm_link+0x42d/0x500 pcie_aspm_set_policy+0x8e/0x1a0 param_attr_store+0x162/0x2c0 module_attr_store+0x3e/0x80PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPMControl value in all functions of multi-function devices.Disable ASPM and free the pcie_link_state when any child function isremoved so we can discard the dangling pcie_link_state->downstream pointerand maintain the same ASPM Control configuration for all functions.[bhelgaas: commit log and comment]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix potential NULL pointer dereferenceKlocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validatepointer before dereferencing the pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()This condition needs to match the previous "if (epcp->state == LISTEN) {"exactly to avoid a NULL dereference of either "listen_ep" or "ep". Theproblem is that "epcp" has been re-assigned so just testing"if (epcp->state == LISTEN) {" a second time is not sufficient.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Add lwtunnel encap size of all siblings in nexthop calculationIn function rt6_nlmsg_size(), the length of nexthop is calculatedby multipling the nexthop length of fib6_info and the number ofsiblings. However if the fib6_info has no lwtunnel but the siblingshave lwtunnels, the nexthop length is less than it should be, andit will trigger a warning in inet6_rt_notify() as follows:WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130......Call Trace: fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70 ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThis bug can be reproduced by script:ip -6 addr add 2002::2/64 dev ens2ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100for i in 10 20 30 40 50 60 70;do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i updonefor i in 10 20 30 40 50 60;do ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1dev ipv_$i metric 100doneip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100This patch fixes it by adding nexthop_len of every siblings usingrt6_nh_nlmsg_size().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix error unwinding of XDP initializationWhen initializing XDP in virtnet_open(), some rq xdp initializationmay hit an error causing net device open failed. However, previousrqs have already initialized XDP and enabled NAPI, which is not theexpected behavior. Need to roll back the previous rq initializationto avoid leaks in error unwinding of init code.Also extract helper functions of disable and enable queue pairs.Use newly introduced disable helper function in error unwinding andvirtnet_close. Use enable helper function in virtnet_open.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()The following call trace was observed:localhost kernel: nvme nvme0: NVME-FC{0}: controller connect completelocalhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]localhost kernel: Call Trace:localhost kernel: dump_stack_lvl+0x57/0x7dlocalhost kernel: check_preemption_disabled+0xc8/0xd0localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]Use raw_smp_processor_id() instead of smp_processor_id().Also use queue_work() across the driver instead of queue_work_on() thusavoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: raspberrypi-ts - fix refcount leak in rpi_ts_proberpi_firmware_get() take reference, we need to release it in error pathsas well. Use devm_rpi_firmware_get() helper to handling the resources.Also remove the existing rpi_firmware_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phyFor some reason, the driver adding support for Exynos5420 MIPI phyback in 2016 wasn't used on Exynos5420, which caused a kernel panic.Add the proper compatible for it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urbThe syzbot fuzzer identified a problem in the usbnet driver:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc9000463f568 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0Call Trace: usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 [inline] netdev_start_xmit include/linux/netdevice.h:4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594...This bug is caused by the fact that usbnet trusts the bulk endpointaddresses its probe routine receives in the driver_info structure, andit does not check to see that these endpoints actually exist and havethe expected type and directions.The fix is simply to add such a check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix use-after-free in free_netdevWe do netif_napi_add() for all allocated q_vectors[], but potentiallydo netif_napi_del() for part of them, then kfree q_vectors and leaveinvalid pointers at dev->napi_list.Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) waitResult:[ 4093.900222] ==================================================================[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699[ 4093.900233][ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021[ 4093.900239] Call Trace:[ 4093.900244] dump_stack+0x71/0xab[ 4093.900249] print_address_description+0x6b/0x290[ 4093.900251] ? free_netdev+0x308/0x390[ 4093.900252] kasan_report+0x14a/0x2b0[ 4093.900254] free_netdev+0x308/0x390[ 4093.900261] iavf_remove+0x825/0xd20 [iavf][ 4093.900265] pci_device_remove+0xa8/0x1f0[ 4093.900268] device_release_driver_internal+0x1c6/0x460[ 4093.900271] pci_stop_bus_device+0x101/0x150[ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20[ 4093.900275] pci_iov_remove_virtfn+0x187/0x420[ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10[ 4093.900278] ? pci_get_subsys+0x90/0x90[ 4093.900280] sriov_disable+0xed/0x3e0[ 4093.900282] ? bus_find_device+0x12d/0x1a0[ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e][ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e][ 4093.900299] ? pci_get_device+0x7c/0x90[ 4093.900300] ? pci_get_subsys+0x90/0x90[ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210[ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e][ 4093.900318] sriov_numvfs_store+0x214/0x290[ 4093.900320] ? sriov_totalvfs_show+0x30/0x30[ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900323] ? __check_object_size+0x15a/0x350[ 4093.900326] kernfs_fop_write+0x280/0x3f0[ 4093.900329] vfs_write+0x145/0x440[ 4093.900330] ksys_write+0xab/0x160[ 4093.900332] ? __ia32_sys_read+0xb0/0xb0[ 4093.900334] ? fput_many+0x1a/0x120[ 4093.900335] ? filp_close+0xf0/0x130[ 4093.900338] do_syscall_64+0xa0/0x370[ 4093.900339] ? page_fault+0x8/0x30[ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 4093.900357] RIP: 0033:0x7f16ad4d22c0[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700[ 4093.9003---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip_vti: fix potential slab-use-after-free in decode_session6When ip_vti device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when ip_vti device sends IPv6 packets.As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix defrag path triggering jbd2 ASSERTcode path:ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERTcrash stacks:PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]AnalysisThis bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: callocfs2_journal_access_di() before ocfs2_journal_dirty() inocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() iscalled by ocfs2_split_extent() during defragmenting.How to fixFor ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller onlyneeds to call journal start/stop pair. The fix method is to removejournal access/dirty from __ocfs2_move_extent().The discussion for this patch:https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: don't leak memory if dev_set_name() failsWhen dev_set_name() fails, zcdn_create() doesn't free the newlyallocated resources. Do it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Release folio lock on fscache read hit.Under the current code, when cifs_readpage_worker is called, the callcontract is that the callee should unlock the page. This is documentedin the read_folio section of Documentation/filesystems/vfs.rst as:> The filesystem should unlock the folio once the read has completed,> whether it was successful or not.Without this change, when fscache is in use and cache hit occurs duringa read, the page lock is leaked, producing the following stack onsubsequent reads (via mmap) to the page:$ cat /proc/3890/task/12864/stack[<0>] folio_wait_bit_common+0x124/0x350[<0>] filemap_read_folio+0xad/0xf0[<0>] filemap_fault+0x8b1/0xab0[<0>] __do_fault+0x39/0x150[<0>] do_fault+0x25c/0x3e0[<0>] __handle_mm_fault+0x6ca/0xc70[<0>] handle_mm_fault+0xe9/0x350[<0>] do_user_addr_fault+0x225/0x6c0[<0>] exc_page_fault+0x84/0x1b0[<0>] asm_exc_page_fault+0x27/0x30This requires a reboot to resolve; it is a deadlock.Note however that the call to cifs_readpage_from_fscache does mark thepage clean, but does not free the folio lock. This happens in__cifs_readpage_from_fscache on success. Releasing the lock at thatpoint however is not appropriate as cifs_readahead also callscifs_readpage_from_fscache and *does* unconditionally release the lockafter its return. This change therefore effectively makescifs_readpage_worker work like cifs_readahead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix resource leak in device_add()When calling kobject_add() failed in device_add(), it will callcleanup_glue_dir() to free resource. But in kobject_add(),dev->kobj.parent has been set to NULL. This will cause resource leak.The process is as follows:device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()The preceding problem may cause insmod mac80211_hwsim.ko to failed.sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'Call Trace:dump_stack_lvl+0x8e/0xd1sysfs_warn_dup.cold+0x1c/0x29sysfs_create_dir_ns+0x224/0x280kobject_add_internal+0x2aa/0x880kobject_add+0x135/0x1a0get_device_parent+0x3d7/0x590device_add+0x2aa/0x1cb0device_create_groups_vargs+0x1eb/0x260device_create+0xdc/0x110mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]do_one_initcall+0x10f/0x630do_init_module+0x19f/0x5e0load_module+0x64b7/0x6eb0__do_sys_finit_module+0x140/0x200do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try toregister things with the same name in the same directory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: base: Free devm resources when unregistering a deviceIn the current code, devres_release_all() only gets called if the devicehas a bus and has been probed.This leads to issues when using bus-less or driver-less devices wherethe device might never get freed if a managed resource holds a referenceto the device. This is happening in the DRM framework for example.We should thus call devres_release_all() in the device_del() function tomake sure that the device-managed actions are properly executed when thedevice is unregistered, even if it has neither a bus nor a driver.This is effectively the same change than commit 2f8d16a996da ("devres:release resources on device_del()") that got reverted by commita525a3ddeaca ("driver core: free devres in device_release") overmemory leaks concerns.This patch effectively combines the two commits mentioned above torelease the resources both on device_del() and device_release() and getthe best of both worlds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix mid leak during reconnection after timeout thresholdWhen the number of responses with status of STATUS_IO_TIMEOUTexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnectthe connection. But we do not return the mid, or the creditsreturned for the mid, or reduce the number of in-flight requests.This bug could result in the server->in_flight count to go bad,and also cause a leak in the mids.This change moves the check to a few lines below where theresponse is decrypted, even of the response is read from thetransform header. This way, the code for returning the midscan be reused.Also, the cifs_reconnect was reconnecting just the transportconnection before. In case of multi-channel, this may not bewhat we want to do after several timeouts. Changed that toreconnect the session and the tree too.Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate nameMAX_STATUS_IO_TIMEOUT.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Avoid fcport pointer dereferenceKlocwork reported warning of NULL pointer may be dereferenced. The routineexits when sa_ctl is NULL and fcport is allocated after the exit call thuscausing NULL fcport pointer to dereference at the time of exit.To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi_si: fix a memleak in try_smi_init()Kmemleak reported the following leak info in try_smi_init():unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180The problem was that when an error occurred before handlers registrationand after allocating `new_smi->si_sm`, the variable wouldn't be freed inthe error handling afterwards since `shutdown_smi()` hadn't beenregistered yet. Fix it by adding a `kfree()` in the error handling pathin `try_smi_init()`.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix deletion race conditionSystem crash when using debug kernel due to link list corruption. The causeof the link list corruption is due to session deletion was allowed to queueup twice. Here's the internal trace that show the same port was allowed todouble queue for deletion on different cpu.20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 120808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1Move the clearing/setting of deleted flag lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix soft lockup in status_resyncstatus_resync() will calculate 'curr_resync - recovery_active' to showuser a progress bar like following:[============>........] resync = 61.4%'curr_resync' and 'recovery_active' is updated in md_do_sync(), andstatus_resync() can read them concurrently, hence it's possible that'curr_resync - recovery_active' can overflow to a huge number. In thiscase status_resync() will be stuck in the loop to print a large amountof '=', which will end up soft lockup.Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,this way resync in progress will be reported to user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.listWhen freeing slots in function slot_complete_v3_hw(), it is possible thatsas_dev.list is being traversed elsewhere, and it may trigger a NULLpointer exception, such as follows:==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task()==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe()[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32[ 7165.434926] sas: trying to find task 0x00000000769b5ba5[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored[ 7165.434976] Mem abort info:[ 7165.434982] ESR = 0x96000004[ 7165.434991] Exception class = DABT (current EL), IL = 32 bits[ 7165.434992] SET = 0, FnV = 0[ 7165.434993] EA = 0, S1PTW = 0[ 7165.434994] Data abort info:[ 7165.434994] ISV = 0, ISS = 0x00000004[ 7165.434995] CM = 0, WnR = 0[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2[ 7165.434998] [0000000000000000] pgd=0000000000000000[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw][ 7165.485247] sp : ffff00001d623bc0[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e[ 7165.567872] Call trace:[ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main][ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas][ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas][ 7165.592082] scsi_error_handler+0xb4/0x488[ 7165.596163] kthread+0x134/0x138[ 7165.599380] ret_from_fork+0x10/0x18[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)[ 7165.609004] kernel fault(0x1) notification starting on CPU 75[ 7165.700728] ---[ end trace fc042cbbea224efc ]---[ 7165.705326] Kernel panic - not syncing: Fatal exceptionTo fix the issue, grab sas_dev lock when traversing the members ofsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoidconcurrency of adding and deleting member. When ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: radio-shark: Add endpoint checksThe syzbot fuzzer was able to provoke a WARNING from the radio-shark2driver:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edacRBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387 shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88...The problem was caused by the fact that the driver does not checkwhether the endpoints it uses are actually present and have theappropriate types. This can be fixed by adding a simple check ofthese endpoints (and similarly for the radio-shark driver).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't dereference ACPI root object handleSince the commit referenced in the Fixes: tag below the VMBus client driveris walking the ACPI namespace up from the VMBus ACPI device to the ACPInamespace root object trying to find Hyper-V MMIO ranges.However, if it is not able to find them it ends trying to walk resources ofthe ACPI namespace root object itself.This object has all-ones handle, which causes a NULL pointer dereferencein the ACPI code (from dereferencing this pointer with an offset).This in turn causes an oops on boot with VMBus host implementations that donot provide Hyper-V MMIO ranges in their VMBus ACPI device or itsancestors.The QEMU VMBus implementation is an example of such implementation.I guess providing these ranges is optional, since all tested Windowsversions seem to be able to use VMBus devices without them.Fix this by explicitly terminating the lookup at the ACPI namespace rootobject.Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interfaceby default - they only do so if the KVM PV interface is missing ordisabled.Example stack trace of such oops:[ 3.710827] ? __die+0x1f/0x60[ 3.715030] ? page_fault_oops+0x159/0x460[ 3.716008] ? exc_page_fault+0x73/0x170[ 3.716959] ? asm_exc_page_fault+0x22/0x30[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0[ 3.723559] ? down_timeout+0x3a/0x60[ 3.724455] ? acpi_ns_get_node+0x3a/0x60[ 3.725412] acpi_ns_get_node+0x3a/0x60[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0[ 3.728400] acpi_rs_get_method_data+0x2b/0x70[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.732411] acpi_walk_resources+0x78/0xd0[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus][ 3.734802] platform_probe+0x3d/0x90[ 3.735684] really_probe+0x19b/0x400[ 3.736570] ? __device_attach_driver+0x100/0x100[ 3.737697] __driver_probe_device+0x78/0x160[ 3.738746] driver_probe_device+0x1f/0x90[ 3.739743] __driver_attach+0xc2/0x1b0[ 3.740671] bus_for_each_dev+0x70/0xc0[ 3.741601] bus_add_driver+0x10e/0x210[ 3.742527] driver_register+0x55/0xf0[ 3.744412] ? 0xffffffffc039a000[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixersmatch error:sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:we previously assumed 'rac97' could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible desc_ptr out-of-bounds accessesSanitize possible desc_ptr out-of-bounds accesses inses_enclosure_data_process().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()There is a memory leak reported by kmemleak: unreferenced object 0xffffc900003f0000 (size 12288): comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx] [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx] [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0The root cause is traced to an error-handling path in qla2x00_probe_one()when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" isused to record the port information and it is allocated inqla2x00_create_host(). However, it is not released in the error handlingpath "probe_failed".Fix this by freeing the memory of "scan.l" when an error occurs in theadapter initialization process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1The type of size is unsigned int, if size is 0x40000000, there willbe an integer overflow, size will be zero after size *= sizeof(uint32_t),will cause uninitialized memory to be referenced later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setupvariable *nplanes is provided by user via system call argument. Thepossible value of q_data->fmt->num_planes is 1-3, while the valueof *nplanes can be 1-8. The array access by index i can cause arrayout-of-bounds.Fix this bug by checking *nplanes against the array size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential use-after-free bugs in TCP_Server_Info::hostnameTCP_Server_Info::hostname may be updated once or many times duringreconnect, so protect its access outside reconnect path as well andthen prevent any potential use-after-free bugs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set()tuning_ctl_set() might have buffer overrun at (X) if it didn't breakfrom loop by matching (A). static int tuning_ctl_set(...) { for (i = 0; i < TUNING_CTLS_COUNT; i++)(A) if (nid == ca0132_tuning_ctls[i].nid) break; snd_hda_power_up(...);(X) dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...); snd_hda_power_down(...); ^ return 1; }We will get below error by cppcheck sound/pci/hda/patch_ca0132.c:4229:2: note: After for loop, i has value 12 for (i = 0; i < TUNING_CTLS_COUNT; i++) ^ sound/pci/hda/patch_ca0132.c:4234:43: note: Array index out of bounds dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20, ^This patch cares non match case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: api - Use work queue in crypto_destroy_instanceThe function crypto_drop_spawn expects to be called in processcontext. However, when an instance is unregistered while it stillhas active users, the last user may cause the instance to be freedin atomic context.Fix this by delaying the freeing to a work queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: htc_hst: free skb in ath9k_htc_rx_msg() if there is no callback functionIt is stated that ath9k_htc_rx_msg() either frees the provided skb orpasses its management to another callback function. However, the skb isnot freed in case there is no another callback function, and Syzkaller wasable to cause a memory leak. Also minor comment fix.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: fix memory leak in mwifiex_histogram_read()Always free the zeroed page on return from 'mwifiex_histogram_read()'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amdgpu: validate offset_in_bo of drm_amdgpu_gem_vaThis is motivated by OOB access in amdgpu_vm_update_range whenoffset_in_bo+map_size overflows.v2: keep the validations in amdgpu_vm_bo_mapv3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map rather than to amdgpu_gem_va_ioctl
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:loop: loop_set_status_from_info() check before assignmentIn loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit shouldbe checked before reassignment, because if an overflow error occurs, theoriginal correct value will be changed to the wrong value, and it will notbe changed back.More, the original patch did not solve the problem, the value was set andioctl returned an error, but the subsequent io used the value in the loopdriver, which still caused an alarm:loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it byupdating kcm_tx_msg(head)->last_skb if partial data is copied so that thefollowing sendmsg() will resume from the skb.However, we cannot know how many bytes were copied when we get the error.Thus, we could mess up the MSG_MORE queue.When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as wedo so for UDP by udp_flush_pending_frames().Even without this change, when the error occurred, the following sendmsg()resumed from a wrong skb and the queue was messed up. However, we haveyet to get such a report, and only syzkaller stumbled on it. So, thiscan be changed safely.Note this does not change SOCK_SEQPACKET behaviour.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: read sk->sk_family once in sk_mc_loop()syzbot is playing with IPV6_ADDRFORM quite a lot these days,and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()We have many more similar issues to fix.WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260Modules linked in:CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023Workqueue: events_power_efficient gc_workerRIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48RSP: 0018:ffffc90000388530 EFLAGS: 00010246RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83[] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline][] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211[] NF_HOOK_COND include/linux/netfilter.h:298 [inline][] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232[] dst_output include/net/dst.h:444 [inline][] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342[] qdisc_restart net/sched/sch_generic.c:407 [inline][] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415[] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125[] net_tx_action+0x7ac/0x940 net/core/dev.c:5247[] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599[] invoke_softirq kernel/softirq.c:430 [inline][] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683[] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iavf: use internal state to free traffic IRQsIf the system tries to close the netdev while iavf_reset_task() isrunning, __LINK_STATE_START will be cleared and netif_running() willreturn false in iavf_reinit_interrupt_scheme(). This will result iniavf_free_traffic_irqs() not being called and a leak as follows: [7632.489326] remove_proc_entry: removing non-empty directory 'irq/999', leaking at least 'iavf-enp24s0f0v0-TxRx-0' [7632.490214] WARNING: CPU: 0 PID: 10 at fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0is shown when pci_disable_msix() is later called. Fix by using theinternal adapter state. The traffic IRQs will always exist ifstate == __IAVF_RUNNING.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate accesses to nlk->cb_runningBoth netlink_recvmsg() and netlink_native_seq_show() readnlk->cb_running locklessly. Use READ_ONCE() there.Add corresponding WRITE_ONCE() to netlink_dump() and__netlink_dump_start()syzbot reported:BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsgwrite to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:__netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399netlink_dump_start include/linux/netlink.h:308 [inline]rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg net/socket.c:747 [inline]sock_write_iter+0x1aa/0x230 net/socket.c:1138call_write_iter include/linux/fs.h:1851 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x463/0x760 fs/read_write.c:584ksys_write+0xeb/0x1a0 fs/read_write.c:637__do_sys_write fs/read_write.c:649 [inline]__se_sys_write fs/read_write.c:646 [inline]__x64_sys_write+0x42/0x50 fs/read_write.c:646do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017____sys_recvmsg+0x2db/0x310 net/socket.c:2718___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x00 -> 0x01
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of errorIf clk_get_rate() fails, the clk that has just been allocated needs to befreed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: do not hard code device address lenth in fdb dumpssyzbot reports that some netdev devices do not have a six bytesaddress [1]Replace ETH_ALEN by dev->addr_len.[1] (Case of a device where dev->addr_len = 4)BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169instrument_copy_to_user include/linux/instrumented.h:114 [inline]copyout+0xb8/0x100 lib/iov_iter.c:169_copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536copy_to_iter include/linux/uio.h:206 [inline]simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970sock_recvmsg_nosec net/socket.c:1019 [inline]sock_recvmsg net/socket.c:1040 [inline]____sys_recvmsg+0x283/0x7f0 net/socket.c:2722___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at:__nla_put lib/nlattr.c:1009 [inline]nla_put+0x1c6/0x230 lib/nlattr.c:1067nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019____sys_recvmsg+0x664/0x7f0 net/socket.c:2720___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at:slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716slab_alloc_node mm/slub.c:3451 [inline]__kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490kmalloc_trace+0x51/0x200 mm/slab_common.c:1057kmalloc include/linux/slab.h:559 [inline]__hw_addr_create net/core/dev_addr_lists.c:60 [inline]__hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118__dev_mc_add net/core/dev_addr_lists.c:867 [inline]dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708addrconf_type_change net/ipv6/addrconf.c:3731 [inline]addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699notifier_call_chain kernel/notifier.c:93 [inline]raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1935 [inline]call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906do_set_master net/core/rtnetlink.c:2626 [inline]rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]__rtnl_newlink net/core/rtnetlink.c:3660 [inline]rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0xf28/0x1230 net/netlink/af_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix potential use-after-free bug when trimming capsWhen trimming the caps and just after the 'session->s_cap_lock' isreleased in ceph_iterate_session_caps() the cap maybe removed byanother thread, and when using the stale cap memory in the callbacksit will trigger use-after-free crash.We need to check the existence of the cap just after the 'ci->i_ceph_lock'being acquired. And do nothing if it's already removed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: virtio - Fix race on data_avail and actual dataThe virtio rng device kicks off a new entropy request whenever thedata available reaches zero. When a new request occurs at the endof a read operation, that is, when the result of that request isonly needed by the next reader, then there is a race between thewriting of the new data and the next reader.This is because there is no synchronisation whatsoever between thewriter and the reader.Fix this by writing data_avail with smp_store_release and readingit with smp_load_acquire when we first enter read. The subsequentreads are safe because they're either protected by the first loadacquire, or by the completion mechanism.Also remove the redundant zeroing of data_idx in random_recv_done(data_idx must already be zero at this point) and data_avail inrequest_entropy (ditto).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while usingIPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)We had a similar report [1] for probably sk_memory_allocated_add()in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fixNULL pointer dereference") fixed it by setting .memory_allocated forudplite_prot and udplitev6_prot.To fix the variant, we need to set either .sysctl_wmem_offset or.sysctl_rmem.Now UDP and UDPLITE share the same value for .memory_allocated, so weuse the same .sysctl_wmem_offset for UDP and UDPLITE.[0]:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8bRSP: 0018:ffffc90005d7f450 EFLAGS: 00010246RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0Call Trace: __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82RIP: 0023:0xf7f21579Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vmci_host: fix a race condition in vmci_host_poll() causing GPFDuring fuzzing, a general protection fault is observed invmci_host_poll().general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf]RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926<- omitting registers ->Call Trace: lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162 add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22 poll_wait include/linux/poll.h:49 [inline] vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174 vfs_poll include/linux/poll.h:88 [inline] do_pollfd fs/select.c:873 [inline] do_poll fs/select.c:921 [inline] do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015 __do_sys_ppoll fs/select.c:1121 [inline] __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x46/0xb0Example thread interleaving that causes the general protection faultis as follows:CPU1 (vmci_host_poll) CPU2 (vmci_host_do_init_context)----- -----// Read uninitialized contextcontext = vmci_host_dev->context; // Initialize context vmci_host_dev->context = vmci_ctx_create(); vmci_host_dev->ct_type = VMCIOBJ_CONTEXT;if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) { // Dereferencing the wrong pointer poll_wait(..., &context->host_context);}In this scenario, vmci_host_poll() reads vmci_host_dev->context first,and then reads vmci_host_dev->ct_type to check thatvmci_host_dev->context is initialized. However, since these two readsare not atomically executed, there is a chance of a race condition asdescribed above.To fix this race condition, read vmci_host_dev->context after checkingthe value of vmci_host_dev->ct_type so that vmci_host_poll() alwaysreads an initialized context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix stack overflow when LRO is disabled for virtual interfacesWhen the virtual interface's feature is updated, it synchronizes theupdated feature for its own lower interface.This propagation logic should be worked as the iteration, not recursively.But it works recursively due to the netdev notification unexpectedly.This problem occurs when it disables LRO only for the team and bondinginterface type. team0 | +------+------+-----+-----+ | | | | |team1 team2 team3 ... team200If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGEevent to its own lower interfaces(team1 ~ team200).It is worked by netdev_sync_lower_features().So, the NETDEV_FEAT_CHANGE notification logic of each lower interfacework iteratively.But generated NETDEV_FEAT_CHANGE event is also sent to the upperinterface too.upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its ownlower interfaces again.lower and upper interfaces receive this event and generate thisevent again and again.So, the stack overflow occurs.But it is not the infinite loop issue.Because the netdev_sync_lower_features() updates features beforegenerating the NETDEV_FEAT_CHANGE event.Already synchronized lower interfaces skip notification logic.So, it is just the problem that iteration logic is changed to therecursive unexpectedly due to the notification mechanism.Reproducer:ip link add team0 type teamethtool -K team0 lro onfor i in {1..200}do ip link add team$i master team0 type team ethtool -K team$i lro ondoneethtool -K team0 lro offIn order to fix it, the notifier_ctx member of bonding/team is introduced.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/hdmi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue as it may returnNULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and`hdmi_hpd.c`.Patchwork: https://patchwork.freedesktop.org/patch/517211/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between balance and cancel/pauseSyzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe reproducer is running a balance and a cancel or pause in parallel.The way balance finishes is a bit wonky, if we were paused we need tosave the balance_ctl in the fs_info, but clear it otherwise and cleanup.However we rely on the return values being specific errors, or having acancel request or no pause request. If balance completes and returns 0,but we have a pause or cancel request we won't do the appropriatecleanup, and then the next time we try to start a balance we'll tripthis ASSERT.The error handling is just wrong here, we always want to clean up,unless we got -ECANCELLED and we set the appropriate pause flag in theexclusive op. With this patch the reproducer ran for an hour withouttripping, previously it would trip in less than a few minutes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix the error "trying to register non-static key in rxe_cleanup_task"In the function rxe_create_qp(), rxe_qp_from_init() is called toinitialize qp, internally things like rxe_init_task are not setup untilrxe_qp_init_req().If an error occurred before this point then the unwind will callrxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()which will oops when trying to access the uninitialized spinlock.If rxe_init_task is not executed, rxe_cleanup_task will not be called.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: dw_hdmi: cleanup drm encoder during unbindThis fixes a use-after-free crash during rmmod.The DRM encoder is embedded inside the larger rockchip_hdmi,which is allocated with the component. The component memorygets freed before the main drm device is destroyed. Fix itby running encoder cleanup before tearing down its container.[moved encoder cleanup above clk_disable, similar to bind-error-path]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Prevent handling any completions after qp destroyHW may generate completions that indicates QP is destroyed.Driver should not be scheduling any more completion handlersfor this QP, after the QP is destroyed. Since CQs are activeduring the QP destroy, driver may still schedule completionhandlers. This can cause a race where the destroy_cq and poll_cqrunning simultaneously.Snippet of kernel panic while doing bnxt_re driver load unload in loop.This indicates a poll after the CQ is freed. [77786.481636] Call Trace:[77786.481640] [77786.481644] bnxt_re_poll_cq+0x14a/0x620 [bnxt_re][77786.481658] ? kvm_clock_read+0x14/0x30[77786.481693] __ib_process_cq+0x57/0x190 [ib_core][77786.481728] ib_cq_poll_work+0x26/0x80 [ib_core][77786.481761] process_one_work+0x1e5/0x3f0[77786.481768] worker_thread+0x50/0x3a0[77786.481785] ? __pfx_worker_thread+0x10/0x10[77786.481790] kthread+0xe2/0x110[77786.481794] ? __pfx_kthread+0x10/0x10[77786.481797] ret_from_fork+0x2c/0x50To avoid this, complete all completion handlers before returning thedestroy QP. If free_cq is called soon after destroy_qp, IB stackwill cancel the CQ work before invoking the destroy_cq verb andthis will prevent any race mentioned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: Fix memleak when insert_old_idx() failedFollowing process will cause a memleak for copied up znode:dirty_cow_znode zn = copy_znode(c, znode); err = insert_old_idx(c, zbr->lnum, zbr->offs); if (unlikely(err)) return ERR_PTR(err); // No one refers to zn.Fetch a reproducer in [Link].Function copy_znode() is split into 2 parts: resource allocationand znode replacement, insert_old_idx() is split in similar way,so resource cleanup could be done in error handling path withoutcorrupting metadata(mem & disk).It's okay that old index inserting is put behind of add_idx_dirt(),old index is used in layout_leb_in_gaps(), so the two processes donot depend on each other.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameterThe 'acpiid' buffer in the parse_ivrs_acpihid function may overflow,because the string specifier in the format string sscanf()has no width limitation.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting free space root from the dirty cow roots listWhen deleting the free space tree we are deleting the free space rootfrom the list fs_info->dirty_cowonly_roots without taking the lock thatprotects it, which is struct btrfs_fs_info::trans_lock.This unsynchronized list manipulation may cause chaos if there's anotherconcurrent manipulation of this list, such as when adding a root to itwith ctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe free space root from that list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: speed up grant-table reclaimWhen a grant entry is still in use by the remote domain, Linux must putit on a deferred list. Normally, this list is very short, becausethe PV network and block protocols expect the backend to unmap the grantfirst. However, Qubes OS's GUI protocol is subject to the constraintsof the X Window System, and as such winds up with the frontend unmappingthe window first. As a result, the list can grow very large, resultingin a massive memory leak and eventual VM freeze.To partially solve this problem, make the number of entries that the VMwill attempt to free at each iteration tunable. The default is still10, but it can be overridden via a module parameter.This is Cc: stable because (when combined with appropriate userspacechanges) it fixes a severe performance and stability problem for QubesOS users.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gvt: fix gvt debugfs destroyWhen gvt debug fs is destroyed, need to have a sane check if drmminor's debugfs root is still available or not, otherwise in case likedevice remove through unbinding, drm minor's debugfs directory hasalready been removed, then intel_gvt_debugfs_clean() would act upondangling pointer like below oops.i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state failed with error -2i915 0000:00:02.0: MDEV: RegisteredConsole: switching to colour dummy device 80x25i915 0000:00:02.0: MDEV: UnregisteringBUG: kernel NULL pointer dereference, address: 00000000000000a0PGD 0 P4D 0Oops: 0002 [#1] PREEMPT SMP PTICPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: G I 6.1.0-rc8+ #15Hardware name: Dell Inc. XPS 13 9350/0JXC1H, BIOS 1.13.0 02/10/2020RIP: 0010:down_write+0x1f/0x90Code: 1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01RSP: 0018:ffff9eb3036ffcc8 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0FS: 00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0Call Trace: simple_recursive_removal+0x9f/0x2a0 ? start_creating.part.0+0x120/0x120 ? _raw_spin_lock+0x13/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_clean+0x15/0x30 [kvmgt] intel_gvt_clean_device+0x49/0xe0 [kvmgt] intel_gvt_driver_remove+0x2f/0xb0 i915_driver_remove+0xa4/0xf0 i915_pci_remove+0x1a/0x30 pci_device_remove+0x33/0xa0 device_release_driver_internal+0x1b2/0x230 unbind_store+0xe0/0x110 kernfs_fop_write_iter+0x11b/0x1f0 vfs_write+0x203/0x3d0 ksys_write+0x63/0xe0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f6947cb5190Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89RSP: 002b:00007ffcbac45a28 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f6947cb5190RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97cR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001R13: 000000000000000d R14: 0000000000000000 R15: 0000555e358cb8e0 Modules linked in: kvmgtCR2: 00000000000000a0---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: rcar_fdp1: Fix refcount leak in probe and remove functionrcar_fcp_get() take reference, which should be balanced withrcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove andthe error paths of fdp1_probe() to fix this.[hverkuil: resolve merge conflict, remove() is now void]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix memory leak in error path of kcm_sendmsg()syzbot reported a memory leak like below:BUG: memory leakunreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [] alloc_skb include/linux/skbuff.h:1289 [inline] [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [] sock_sendmsg_nosec net/socket.c:725 [inline] [] sock_sendmsg+0x56/0xb0 net/socket.c:748 [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to appendnewly allocated skbs to 'head'. If some bytes are copied, an error occurred,and jumped to out_error label, 'last_skb' is left unmodified. A laterkcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the'head' frag_list and causing the leak.This patch fixes this issue by properly updating the last allocated skb in'last_skb'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeIn production we were seeing a variety of WARN_ON()'s in the extent_mapcode, specifically in btrfs_drop_extent_map_range() when we have to calladd_extent_mapping() for our second split.Consider the following extent map layout PINNED [0 16K) [32K, 48K)and then we call btrfs_drop_extent_map_range for [0, 36K), withskip_pinned == true. The initial loop will have start = 0 end = 36K len = 36Kwe will find the [0, 16k) extent, but since we are pinned we will skipit, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end;em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36Klen should instead be 20K. This is a problem when we find the nextextent at [32K, 48K), we need to split this extent to leave [36K, 48k),however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len);In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52Kand now we have an invalid extent_map in the tree that potentiallyoverlaps other entries in the extent map. Even in the non-overlappingcase we will have split->start set improperly, which will cause problemswith any block related calculations.We don't actually need len in this loop, we can simply use end as ourend point, and only adjust start up when we find a pinned extent we needto skip.Adjust the logic to do this, which keeps us from inserting an invalidextent map.We only skip_pinned in the relocation case, so this is relatively rare,except in the case where you are running relocation a lot, which canhappen with auto relocation on.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()Syzkaller reported the following issue:=======================================Too BIG xdp->frame_sz = 131072WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103...Call Trace: bpf_prog_4add87e5301a4105+0x1a/0x1c __bpf_prog_run include/linux/filter.h:600 [inline] bpf_prog_run_xdp include/linux/filter.h:775 [inline] bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721 netif_receive_generic_xdp net/core/dev.c:4807 [inline] do_xdp_generic+0x35c/0x770 net/core/dev.c:4866 tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043 call_write_iter include/linux/fs.h:1871 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x650/0xe40 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdxdp->frame_sz > PAGE_SIZE check was introduced in commit c8741e2bfe87("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But JesperDangaard Brouer noted that after introducing thexdp_init_buff() which all XDP driver use - it's safe to remove thischeck. The original intend was to catch cases where XDP drivers havenot been updated to use xdp.frame_sz, but that is not longer a concern(since xdp_init_buff).Running the initial syzkaller repro it was discovered that thecontiguous physical memory allocation is used for both xdp paths intun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was alsostated by Jesper Dangaard Brouer that XDP canwork on higher order pages, as long as this is contiguous physicalmemory (e.g. a page).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_sdei: Fix sleep from invalid context BUGRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altratriggers: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20sdei_cpuhp_up() is called in the STARTING hotplug section,which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entryinstead to execute the cpuhp cb later, with preemption enabled.SDEI originally got its own cpuhp slot to allow interactingwith perf. It got superseded by pNMI and this early slot is notrelevant anymore. [1]Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on thecalling CPU. It is checked that preemption is disabled for them._ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.Preemption is enabled in those threads, but their cpumask is limitedto 1 CPU.Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cbdon't trigger them.Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI callwhich acts on the calling CPU.[1]:https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsit: Free cmds before session freeCommands from recovery entries are freed after session has been closed.That leads to use-after-free at command free or NPE with such call trace:Time2Retain timer expired for SID: 1, cleaning up iSCSI session.BUG: kernel NULL pointer dereference, address: 0000000000000140RIP: 0010:sbitmap_queue_clear+0x3a/0xa0Call Trace: target_release_cmd_kref+0xd1/0x1f0 [target_core_mod] transport_generic_free_cmd+0xd1/0x180 [target_core_mod] iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod] iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod] iscsit_close_session+0x13a/0x140 [iscsi_target_mod] iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod] call_timer_fn+0x24/0x140Move cleanup of recovery enrties to before session freeing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: fix out-of-bounds access in tty_driver_lookup_tty()When specifying an invalid console= device like console=tty3270,tty_driver_lookup_tty() returns the tty struct without checkingwhether index is a valid number.To reproduce:qemu-system-x86_64 -enable-kvm -nographic -serial mon:stdio \-kernel ../linux-build-x86/arch/x86/boot/bzImage \-append "console=ttyS0 console=tty3270"This crashes with:[ 0.770599] BUG: kernel NULL pointer dereference, address: 00000000000000ef[ 0.771265] #PF: supervisor read access in kernel mode[ 0.771773] #PF: error_code(0x0000) - not-present page[ 0.772609] Oops: 0000 [#1] PREEMPT SMP PTI[ 0.774878] RIP: 0010:tty_open+0x268/0x6f0[ 0.784013] chrdev_open+0xbd/0x230[ 0.784444] ? cdev_device_add+0x80/0x80[ 0.784920] do_dentry_open+0x1e0/0x410[ 0.785389] path_openat+0xca9/0x1050[ 0.785813] do_filp_open+0xaa/0x150[ 0.786240] file_open_name+0x133/0x1b0[ 0.786746] filp_open+0x27/0x50[ 0.787244] console_on_rootfs+0x14/0x4d[ 0.787800] kernel_init_freeable+0x1e4/0x20d[ 0.788383] ? rest_init+0xc0/0xc0[ 0.788881] kernel_init+0x11/0x120[ 0.789356] ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: fix race condition UAF in i915_perf_add_config_ioctlUserspace can guess the id value and try to race oa_config object creationwith config remove, resulting in a use-after-free if we dereference theobject after unlocking the metrics_lock. For that reason, unlocking themetrics_lock must be done after we are done dereferencing the object.[tursulin: Manually added stable tag.](cherry picked from commit 49f6f6483b652108bcb73accd0204a464b922395)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: EC: Fix oops when removing custom query handlersWhen removing custom query handlers, the handler might stillbe used inside the EC query workqueue, causing a kernel oopsif the module holding the callback function was already unloaded.Fix this by flushing the EC query workqueue when removingcustom query handlers.Tested on a Acer Travelmate 4002WLMi
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: av7110: prevent underflow in write_ts_to_decoder()The buf[4] value comes from the user via ts_play(). It is a value inthe u8 range. The final length we pass to av7110_ipack_instant_repack()is "len - (buf[4] + 1) - 4" so add a check to ensure that the length isnot negative. It's not clear that passing a negative len value doesanything bad necessarily, but it's not best practice.With the new bounds checking the "if (!len)" condition is no longerpossible or required so remove that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: imx: disable Ageing Timer interrupt request irqThere maybe pending USR interrupt before requesting irq, howeveruart_add_one_port has not executed, so there will be kernel panic:[ 0.795668] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080[ 0.802701] Mem abort info:[ 0.805367] ESR = 0x0000000096000004[ 0.808950] EC = 0x25: DABT (current EL), IL = 32 bits[ 0.814033] SET = 0, FnV = 0[ 0.816950] EA = 0, S1PTW = 0[ 0.819950] FSC = 0x04: level 0 translation fault[ 0.824617] Data abort info:[ 0.827367] ISV = 0, ISS = 0x00000004[ 0.831033] CM = 0, WnR = 0[ 0.833866] [0000000000000080] user address but active_mm is swapper[ 0.839951] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 0.845953] Modules linked in:[ 0.848869] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.1+g56321e101aca #1[ 0.855617] Hardware name: Freescale i.MX8MP EVK (DT)[ 0.860452] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 0.867117] pc : __imx_uart_rxint.constprop.0+0x11c/0x2c0[ 0.872283] lr : imx_uart_int+0xf8/0x1ecThe issue only happends in the inmate linux when Jailhouse hypervisorenabled. The test procedure is:while true; do jailhouse enable imx8mp.cell jailhouse cell linux xxxx sleep 10 jailhouse cell destroy 1 jailhouse disable sleep 5doneAnd during the upper test, press keys to the 2nd linux console.When `jailhouse cell destroy 1`, the 2nd linux has no chance to putthe uart to a quiese state, so USR1/2 may has pending interrupts. Thenwhen `jailhosue cell linux xx` to start 2nd linux again, the issuetrigger.In order to disable irqs before requesting them, both UCR1 and UCR2 irqsshould be disabled, so here fix that, disable the Ageing Timer interruptin UCR2 as UCR1 does.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel: quark_dts: fix error pointer dereferenceIf alloc_soc_dts() fails, then we can just return. Trying to free"soc_dts" will lead to an Oops.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: bus: verify partner exists in typec_altmode_attentionSome usb hubs will negotiate DisplayPort Alt mode with the devicebut will then negotiate a data role swap after entering the altmode. The data role swap causes the device to unregister all altmodes, however the usb hub will still send Attention messageseven after failing to reregister the Alt Mode. type_altmode_attentioncurrently does not verify whether or not a device's altmode partnerexists, which results in a NULL pointer error when dereferencingthe typec_altmode and typec_altmode_ops belonging to the altmodepartner.Verify the presence of a device's altmode partner before sendingthe Attention message to the Alt Mode driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix deadlock when converting an inline directory in nojournal modeIn no journal mode, ext4_finish_convert_inline_dir() can self-deadlockby calling ext4_handle_dirty_dirblock() when it already has taken thedirectory lock. There is a similar self-deadlock inext4_incvert_inline_data_nolock() for data files which we'll fix atthe same time.A simple reproducer demonstrating the problem: mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64 mount -t ext4 -o dirsync /dev/vdc /vdc cd /vdc mkdir file0 cd file0 touch file0 touch file1 attr -s BurnSpaceInEA -V abcde . touch supercalifragilisticexpialidocious
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: af9005: Fix null-ptr-deref in af9005_i2c_xferIn af9005_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9005_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix potential null-ptr-deref in device_add()I got the following null-ptr-deref report while doing fault injection test:BUG: kernel NULL pointer dereference, address: 0000000000000058CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+RIP: 0010:klist_put+0x2d/0xd0Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482]This is how it happened:w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device. // error path bus_remove_device() // The dev->driver is not null, but driver is not bound. __device_release_driver() klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref. // normal path bus_probe_device() // It's not called yet. device_bind_driver()If dev->driver is set, in the error path after calling bus_add_device()in device_add(), bus_remove_device() is called, then the device will bedetached from driver. But device_bind_driver() is not called yet, so itcauses null-ptr-deref while access the 'knode_driver'. To fix this, setdev->driver to null in the error path before calling bus_remove_device().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible addl_desc_ptr out-of-bounds accessesSanitize possible addl_desc_ptr out-of-bounds accesses inses_enclosure_data_process().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: linux-pam (aka Linux PAM) before 1.6.0 allows attackers to cause a denial of service (blocked login process) via mkfifo because the openat call (for protect_dir) lacks O_DIRECTORY.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- pam < 1.1.8-24.56.1 (version in image is 1.1.8-24.49.1).
-
Description: In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error pathWhen calling mlxsw_sp_acl_tcam_region_destroy() from an error path afterfailing to attach the region to an ACL group, we hit a NULL pointerdereference upon 'region->group->tcam' [1].Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0[...]Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRPIf the external phy working together with phy-omap-usb2 does not implementsend_srp(), we may still attempt to call it. This can happen on an idleEthernet gadget triggering a wakeup for example:configfs-gadget.g1 gadget.0: ECM Suspendconfigfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup...Unable to handle kernel NULL pointer dereference at virtual address00000000 when execute...PC is at 0x0LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]...musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24cdev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4sch_direct_xmit from __dev_queue_xmit+0x334/0xd88__dev_queue_xmit from arp_solicit+0xf0/0x268arp_solicit from neigh_probe+0x54/0x7cneigh_probe from __neigh_event_send+0x22c/0x47c__neigh_event_send from neigh_resolve_output+0x14c/0x1c0neigh_resolve_output from ip_finish_output2+0x1c8/0x628ip_finish_output2 from ip_send_skb+0x40/0xd8ip_send_skb from udp_send_skb+0x124/0x340udp_send_skb from udp_sendmsg+0x780/0x984udp_sendmsg from __sys_sendto+0xd8/0x158__sys_sendto from ret_fast_syscall+0x0/0x58Let's fix the issue by checking for send_srp() and set_vbus() beforecalling them. For USB peripheral only cases these both could be NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix illegal rmb_desc access in SMC-D connection dumpA crash was found when dumping SMC-D connections. It can be reproducedby following steps:- run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76It is possible that the connection is in process of being establishedwhen we dump it. Assumed that the connection has been registered in alink group by smc_conn_create() but the rmb_desc has not yet beeninitialized by smc_buf_create(), thus causing the illegal access toconn->rmb_desc. So fix it by checking before dump.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:llc: call sock_orphan() at release timesyzbot reported an interesting trace [1] caused by a stale sk->sk_wqpointer in a closed llc socket.In commit ff7b11aa481f ("net: socket: set sock->sk to NULL aftercalling proto_ops::release()") Eric Biggers hinted that some protocolsare missing a sock_orphan(), we need to perform a full audit.In net-next, I plan to clear sock->sk from sock_orphan() andamend Eric patch to add a warning.[1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bFreed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.Reading frag_off can only be done if we pulled enough bytesto skb->head. Currently we might access garbage.[1]BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432__netdev_start_xmit include/linux/netdevice.h:4940 [inline]netdev_start_xmit include/linux/netdevice.h:4954 [inline]xmit_one net/core/dev.c:3548 [inline]dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349dev_queue_xmit include/linux/netdevice.h:3134 [inline]neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592neigh_output include/net/neighbour.h:542 [inline]ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222NF_HOOK_COND include/linux/netfilter.h:303 [inline]ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243dst_output include/net/dst.h:451 [inline]ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847sock_sendmsg_nosec net/socket.c:730 [inline]__sock_sendmsg net/socket.c:745 [inline]____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638__sys_sendmsg net/socket.c:2667 [inline]__do_sys_sendmsg net/socket.c:2676 [inline]__se_sys_sendmsg net/socket.c:2674 [inline]__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at:slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768slab_alloc_node mm/slub.c:3478 [inline]__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517__do_kmalloc_node mm/slab_common.c:1006 [inline]__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]pskb_may_pull include/linux/skbuff.h:2681 [inline]ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432__netdev_start_xmit include/linux/netdevice.h:4940 [inline]netdev_start_xmit include/linux/netdevice.h:4954 [inline]xmit_one net/core/dev.c:3548 [inline]dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349dev_queue_xmit include/linux/netdevice.h:3134 [inline]neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592neigh_output include/net/neighbour.h:542 [inline]ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222NF_HOOK_COND include/linux/netfilter.h:303 [inline]ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243dst_output include/net/dst.h:451 [inline]ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847sock_sendmsg_nosec net/socket.c:730 [inline]__sock_sendmsg net/socket.c:745 [inline]____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638__sys_sendmsg net/socket.c:2667 [inline]__do_sys_sendms---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:llc: make llc_ui_sendmsg() more robust against bonding changessyzbot was able to trick llc_ui_sendmsg(), allocating an skb with noheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]Like some others, llc_ui_sendmsg() releases the socket lock beforecalling sock_alloc_send_skb().Then it acquires it again, but does not redo all the sanity checksthat were performed.This fix:- Uses LL_RESERVED_SPACE() to reserve space.- Check all conditions again after socket lock is held again.- Do not account Ethernet header for mtu limitation.[1]skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 !Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203sp : ffff800096f97000x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261cex17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't abort filesystem when attempting to snapshot deleted subvolumeIf the source file descriptor to the snapshot ioctl refers to a deletedsubvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? handle_bug+0x3a/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? create_pending_snapshot+0x1040/0x1190 [btrfs] create_pending_snapshots+0x92/0xc0 [btrfs] btrfs_commit_transaction+0x66b/0xf40 [btrfs] btrfs_mksubvol+0x301/0x4d0 [btrfs] btrfs_mksnapshot+0x80/0xb0 [btrfs] __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs] btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs] btrfs_ioctl+0x8a6/0x2650 [btrfs] ? kmem_cache_free+0x22/0x340 ? do_sys_openat2+0x97/0xe0 __x64_sys_ioctl+0x97/0xd0 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entryThis happens because create_pending_snapshot() initializes the new rootitem as a copy of the source root item. This includes the refs field,which is 0 for a deleted subvolume. The call to btrfs_insert_root()therefore inserts a root with refs == 0. btrfs_get_new_fs_root() thenfinds the root and returns -ENOENT if refs == 0, which causescreate_pending_snapshot() to abort.Fix it by checking the source root's refs before attempting thesnapshot, but after locking subvol_sem to avoid racing with deletion.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: handle isoc Babble and Buffer Overrun events properlyxHCI 4.9 explicitly forbids assuming that the xHC has released itsownership of a multi-TRB TD when it reports an error on one of theearly TRBs. Yet the driver makes such assumption and releases the TD,allowing the remaining TRBs to be freed or overwritten by new TDs.The xHC should also report completion of the final TRB due to its IOCflag being set by us, regardless of prior errors. This event cannotbe recognized if the TD has already been freed earlier, resulting in"Transfer event TRB DMA ptr not part of current TD" error message.Fix this by reusing the logic for processing isoc Transaction Errors.This also handles hosts which fail to report the final completion.Fix transfer length reporting on Babble errors. They may be caused bydevice malfunction, no guarantee that the buffer has been filled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()syzbot reported the following general protection fault [1]:general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]...RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291...Call Trace: tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bThe cause of this issue is that when tipc_nl_bearer_add() is called withthe TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is calledeven if the bearer is not UDP.tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes thatthe media_ptr field of the tipc_bearer has an udp_bearer type object, sothe function goes crazy for non-UDP bearers.This patch fixes the issue by checking the bearer type before callingtipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_limit: reject configurations that cause integer overflowReject bogus configs where internal token counter wraps around.This only occurs with very very large requests, such as 17gbyte/s.Its better to reject this rather than having incorrect ratelimit.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix IO hang from sbitmap wakeup raceIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-orderedwith the following blk_mq_get_driver_tag() in case of getting drivertag failure.Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observethe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantimeblk_mq_mark_tag_wait() can't get driver tag successfully.This issue can be reproduced by running the following test in loop, andfio hang can be observed in < 30min when running it on my test VMin laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaioFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), whichis just fine in case of running out of tag.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp_async: limit MRU to 64Ksyzbot triggered a warning [1] in __alloc_pages():WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)[1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543Modules linked in:CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events_unbound flush_to_ldiscpstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537sp : ffff800093967580x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003fx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix delayed ACKs to not set the reference serial numberFix the construction of delayed ACKs to not set the reference serial numberas they can't be used as an RTT reference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet: read sk->sk_family once in inet_recv_error()inet_recv_error() is called without holding the socket lock.IPv6 socket could mutate to IPv4 with IPV6_ADDRFORMsocket option and trigger a KCSAN warning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: close evtchn after mapping cleanupshutdown_pirq and startup_pirq are not taking theirq_mapping_update_lock because they can't due to lock inversion. Bothare called with the irq_desc->lock being taking. The lock order,however, is first irq_mapping_update_lock and then irq_desc->lock.This opens multiple races:- shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1).- __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq.The fix is to first cleanup the mappings and then close the eventchannel. In this way, when an event channel gets allocated it'spotential previous evtchn_to_irq mappings are guaranteed to be unset already.This is also the reverse order of the allocation where first the eventchannel is allocated and then the mappings are setup.On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal[un]bind interfaces"), we hit a BUG like the following during probing of NVMedevices. The issue is that during nvme_setup_io_queues, pci_free_irqis called for every device which results in a call to shutdown_pirq.With many nvme devices it's therefore likely to hit this race duringboot because there will be multiple calls to shutdown_pirq andstartup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: prevent use-after-free in encode_cap_msg()In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error wascaught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. Thisimplies before the refcount could be increment here, it was freed.In same file, in "handle_cap_grant()" refcount is decremented by thisline - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a raceoccurred and resource was freed by the latter line before the formerline could increment it.encode_cap_msg() is called by __send_cap() and __send_cap() is called byceph_check_caps() after calling __prep_cap(). __prep_cap() is wherearg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot wherethe refcount must be increased to prevent "use after free" error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double-free of blocks due to wrong extents moved_lenIn ext4_move_extents(), moved_len is only updated when all moves aresuccessfully executed, and only discards orig_inode and donor_inodepreallocations when moved_len is not zero. When the loop fails to exitafter successfully moving some extents, moved_len is not updated andremains at 0, so it does not discard the preallocations.If the moved extents overlap with the preallocated extents, theoverlapped extents are freed twice in ext4_mb_release_inode_pa() andext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free isincremented twice. Hence when trim is executed, a zero-division bug istriggered in mb_update_avg_fragment_size() because bb_free is not zeroand bb_fragments is zero.Therefore, update move_len after each extent move to avoid the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arp: Prevent overflow in arp_req_get().syzkaller reported an overflown write in arp_req_get(). [0]When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbourentry and copies neigh->ha to struct arpreq.arp_ha.sa_data.The arp_ha here is struct sockaddr, not struct sockaddr_storage, sothe sa_data buffer is just 14 bytes.In the splat below, 2 bytes are overflown to the next int field,arp_flags. We initialise the field just after the memcpy(), so it'snot a problem.However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)in arp_ioctl() before calling arp_req_get().To avoid the overflow, let's limit the max length of memcpy().Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexiblearray in struct sockaddr") just silenced syzkaller.[0]:memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128Modules linked in:CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6RSP: 0018:ffffc900050b7998 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xceRIP: 0033:0x7f172b262b8dCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8dRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix possible use-after-free and null-ptr-derefThe pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: don't override retval if we already lost the skbIf we're redirecting the skb, and haven't called tcf_mirred_forward(),yet, we need to tell the core to drop the skb by setting the retcodeto SHOT. If we have called tcf_mirred_forward(), however, the skbis out of our hands and returning SHOT will lead to UaF.Move the retval override to the error path which actually need it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: use the backlog for mirred ingressThe test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlogfor nested calls to mirred ingress") hangs our testing VMs every 10 or soruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported bylockdep.The problem as previously described by Davide (see Link) is thatif we reverse flow of traffic with the redirect (egress -> ingress)we may reach the same socket which generated the packet. And we maystill be holding its socket lock. The common solution to such deadlocksis to put the packet in the Rx backlog, rather than run the Rx pathinline. Do that for all egress -> ingress reversals, not just oncewe started to nest mirred calls.In the past there was a concern that the backlog indirection willlead to loss of error reporting / less accurate stats. But the currentworkaround does not seem to address the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Support specifying the srpt_service_guid parameterMake loading ib_srpt with this parameter set work. The current behavior isthat setting that parameter while loading the ib_srpt kernel moduletriggers the following kernel crash:BUG: kernel NULL pointer dereference, address: 0000000000000000Call Trace: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()The gtp_net_ops pernet operations structure for the subsystem must beregistered before registering the generic netlink family.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:general protection fault, probably for non-canonical address0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74RSP: 0018:ffff888014107220 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt: don't modify the data when using authenticated encryptionIt was said that authenticated encryption could produce invalid tag whenthe data that is being encrypted is modified [1]. So, fix this problem bycopying the data into the clone bio first and then encrypt them inside theclone bio.This may reduce performance, but it is needed to prevent the user fromcorrupting the device by writing data with O_DIRECT and modifying them atthe same time.[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Add some null pointer checks to the edma_probedevm_kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()Places the logic for checking if the group's block bitmap is corrupt underthe protection of the group lock to avoid allocating blocks from the groupwith a corrupted block bitmap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()Determine if the group block bitmap is corrupted before using ac_b_ex inext4_mb_try_best_found() to avoid allocating blocks from a group with acorrupted block bitmap in the following concurrency and making thesituation worse.ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:aoe: avoid potential deadlock at set_capacityMove set_capacity() outside of the section procected by (&d->lock).To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ----[1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); [4] lock(&d->lock); *** DEADLOCK ***Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.In this situation an attempt to acquire [4]lock(&d->lock) fromaoecmd_cfg_rsp() will lead to deadlock.So the simplest solution is breaking lock dependency[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()outside.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: sis: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn't check the value of pixclock,it may cause divide-by-zero error.In sisfb_check_var(), var->pixclock is used as a divisor to caculatedrate before it is checked against zero. Fix this by checking itat the beginning.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: savage: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn't check the value of pixclock,it may cause divide-by-zero error.Although pixclock is checked in savagefb_decode_var(), but it is notchecked properly in savagefb_probe(). Fix this by checking whetherpixclock is zero in the function savagefb_check_var() beforeinfo->var.pixclock is used as the divisor.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix race condition on enabling fast-xmitfast-xmit must only be enabled after the sta has been uploaded to the driver,otherwise it could end up passing the not-yet-uploaded sta via drv_tx callsto the driver, leading to potential crashes because of uninitialized drv_privdata.Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: dev-replace: properly validate device namesThere's a syzbot report that device name buffers passed to devicereplace are not properly checked for string termination which could leadto a read out of bounds in getname_kernel().Add a helper that validates both source and target device name buffers.For devid as the source initialize the buffer to empty string in casesomething tries to read it later.This was originally analyzed and fixed in a different way by Edward AdamDavis (see links).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_newlink()The gtp_link_ops operations structure for the subsystem must beregistered after registering the gtp_net_ops pernet operations structure.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:[ 1010.702740] gtp: GTP module unloaded[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f][ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0[ 1010.715968] PKRU: 55555554[ 1010.715972] Call Trace:[ 1010.715985] ? __die_body.cold+0x1a/0x1f[ 1010.715995] ? die_addr+0x43/0x70[ 1010.716002] ? exc_general_protection+0x199/0x2f0[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp][ 1010.716042] __rtnl_newlink+0x1063/0x1700[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0[ 1010.716076] ? __kernel_text_address+0x56/0xa0[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30[ 1010.716098] ? arch_stack_walk+0x9e/0xf0[ 1010.716106] ? stack_trace_save+0x91/0xd0[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170[ 1010.716121] ? __lock_acquire+0x15c5/0x5380[ 1010.716139] ? mark_held_locks+0x9e/0xe0[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700[ 1010.716160] rtnl_newlink+0x69/0xa0[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716179] ? lock_acquire+0x1fe/0x560[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50[ 1010.716196] netlink_rcv_skb+0x14d/0x440[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716208] ? netlink_ack+0xab0/0xab0[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50[ 1010.716226] ? __virt_addr_valid+0x30b/0x590[ 1010.716233] netlink_unicast+0x54b/0x800[ 1010.716240] ? netlink_attachskb+0x870/0x870[ 1010.716248] ? __check_object_size+0x2de/0x3b0[ 1010.716254] netlink_sendmsg+0x938/0xe40[ 1010.716261] ? netlink_unicast+0x800/0x800[ 1010.716269] ? __import_iovec+0x292/0x510[ 1010.716276] ? netlink_unicast+0x800/0x800[ 1010.716284] __sock_sendmsg+0x159/0x190[ 1010.716290] ____sys_sendmsg+0x712/0x880[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270[ 1010.716309] ? lock_acquire+0x1fe/0x560[ 1010.716315] ? drain_array_locked+0x90/0x90[ 1010.716324] ___sys_sendmsg+0xf8/0x170[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170[ 1010.716337] ? lockdep_init_map---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Avoid potential use-after-free in hci_error_resetWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlyingBT controller is not responding, the GPIO reset mechanism wouldfree the hci_dev and lead to a use-after-free in hci_error_reset.Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30This patch holds the reference count on the hci_dev while processinga HCI_EV_HARDWARE_ERROR event to avoid potential crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets' ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix kernel-infoleak-after-free in __skb_datagram_itersyzbot reported the following uninit-value access issue [1]:netlink_to_full_skb() creates a new `skb` and puts the `skb->data`passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The datasize is specified as `len` and passed to skb_put_data(). This `len`is based on `skb->end` that is not data offset but buffer offset. The`skb->end` contains data and tailroom. Since the tailroom is notinitialized when the new `skb` created, KMSAN detects uninitializedmemory area when copying the data.This patch resolved this issue by correct the len from `skb->end` to`skb->len`, which is the actual data offset.BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86, relocs: Ignore relocations in .notes sectionWhen building with CONFIG_XEN_PV=y, .text symbols are emitted intothe .notes section so that Xen can find the "startup_xen" entry point.This information is used prior to booting the kernel, so relocationsare not useful. In fact, performing relocations against the .notessection means that the KASLR base is exposed since /sys/kernel/notesis world-readable.To avoid leaking the KASLR base without breaking unprivileged tools thatare expecting to read /sys/kernel/notes, skip performing relocations inthe .notes section. The values readable in .notes are then identical tothose found in System.map.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amdkfd: use calloc instead of kzalloc to avoid integer overflowThis uses calloc instead of doing the multiplication which mightoverflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: free rx_data_reassembly skb on NCI device cleanuprx_data_reassembly skb is stored during NCI data exchange for processingfragmented packets. It is dropped only when the last fragment is processedor when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.However, the NCI device may be deallocated before that which leads to skbleak.As by design the rx_data_reassembly skb is bound to the NCI device andnothing prevents the device to be freed before the skb is processed insome way and cleaned, free it on the NCI device cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not allow untrusted VF to remove administratively set MACCurrently when PF administratively sets VF's MAC address and the VFis put down (VF tries to delete all MACs) then the MAC is removedfrom MAC filters and primary VF MAC is zeroed.Do not allow untrusted VF to remove primary MAC when it was setadministratively by PF.Reproducer:1) Create VF2) Set VF interface up3) Administratively set the VF's MAC4) Put VF interface down[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs[root@host ~]# ip link set enp2s0f0v0 up[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off[root@host ~]# ip link set enp2s0f0v0 down[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: core: Add TMF to tmr_list handlingAn abort that is responded to by iSCSI itself is added to tmr_list but doesnot go to target core. A LUN_RESET that goes through tmr_list takes arefcounter on the abort and waits for completion. However, the abort willbe never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod]Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0To fix this, only add abort to tmr_list if it will be handled by targetcore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: Add protection for bmp length out of rangeUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shiftsthat are out of bounds for their data type.vmlinux get_bitmap(b=75) + 712vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216vmlinux DecodeRasMessage() + 304vmlinux ras_help() + 684vmlinux nf_confirm() + 188Due to abnormal data in skb->data, the extension bitmap lengthexceeds 32 when decoding ras message then uses the length to makea shift operation. It will change into negative after several loop.UBSAN load could detect a negative shift as an undefined behaviourand reports exception.So we add the protection to avoid the length exceeding 32. Or elseit will return out of range error and stop decoding.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()The function ice_bridge_setlink() may encounter a NULL pointer dereferenceif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequentlyin nla_for_each_nested(). To address this issue, add a check to ensure thatbr_spec is not NULL before proceeding with the nested attribute iteration.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:geneve: make sure to pull inner header in geneve_rx()syzbot triggered a bug in geneve_rx() [1]Issue is similar to the one I fixed in commit 8d975c15c0cd("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.[1]BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/bnx2x: Prevent access to a freed page in page_poolFix race condition leading to system crash during EEH error handlingDuring EEH error recovery, the bnx2x driver's transmit timeout logiccould cause a race condition when handling reset tasks. Thebnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()SGEs are freed using bnx2x_free_rx_sge_range(). However, this couldoverlap with the EEH driver's attempt to reset the device usingbnx2x_io_slot_reset(), which also tries to free SGEs. This racecondition can result in system crashes due to accessing freed memorylocations in bnx2x_free_rx_sge()799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,800 struct bnx2x_fastpath *fp, u16 index)801 {802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];803 struct page *page = sw_buf->page;....where sw_buf was set to NULL after the call to dma_unmap_page()by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64To solve this issue, we need to verify page pool allocations beforefreeing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in hsr_get_node()KMSAN reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023=====================================================If the packet type ID field in the Ethernet header is either ETH_P_PRP orETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()reads an invalid value as a sequence number. This causes the above issue.This patch fixes the issue by returning NULL if the Ethernet header is notfollowed by an HSR tag.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Do not register event handler until srpt device is fully setupUpon rare occasions, KASAN reports a use-after-free Writein srpt_refresh_port().This seems to be because an event handler is registered before thesrpt device is fully setup and a race condition upon error may leave apartially setup event handler in place.Instead, only register the event handler after srpt device initializationis complete.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipIt's possible that mtk_crtc->event is NULL inmtk_drm_crtc_finish_page_flip().pending_needs_vblank value is set by mtk_crtc->event, but inmtk_drm_crtc_atomic_flush(), it's is not guarded by the samelock in mtk_drm_finish_page_flip(), thus a race condition happens.Consider the following case:CPU1 CPU2step 1:mtk_drm_crtc_atomic_begin()mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event)step 2:mtk_crtc_ddp_irq ->mtk_drm_finish_page_flip:lockmtk_crtc->event set to null,pending_needs_vblank set to falseunlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointerInstead of guarding the entire mtk_drm_crtc_atomic_flush(), it's moreefficient to just check if mtk_crtc->event is null before use.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: adv7511: fix crash on irq during probeMoved IRQ registration down to end of adv7511_probe().If an IRQ already is pending during adv7511_probe(before adv7511_cec_init) then cec_received_msg_tscould crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:quota: Fix potential NULL pointer dereferenceBelow race may cause NULL pointer dereferenceP1 P2dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) ....If dquot_free_inode(or other routines) checks inode's quota pointers (1)before quota_off sets it to NULL(2) and use it (3) after that, NULL pointerdereference will be triggered.So let's fix it by using a temporary pointer to avoid this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()Apply the same fix than ones found in :8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.syzbot reported:BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: af_bluetooth: Fix deadlockAttemting to do sock_lock on .recvmsg may cause a deadlock as shownbellow, so instead of using sock_sock this uses sk_receive_queue.lockon bt_sock_ioctl to avoid the UAF:INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183Workqueue: hci0 hci_rx_workCall Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()After unregistering the CPU idle device, the memory associated withit is not freed, leading to a memory leak:unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50Fix this by freeing the CPU idle device after unregistering it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix kmemleak of rdev->serialIf kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will bealloc not be freed, and kmemleak occurs.unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_securityDuring our fuzz testing of the connection and disconnection process at theRFCOMM layer, we discovered this bug. By comparing the packets from anormal connection and disconnection process with the testcase thattriggered a KASAN report. We analyzed the cause of this bug as follows:1. In the packets captured during a normal connection, the host sends a`Read Encryption Key Size` type of `HCI_CMD` packet(Command Opcode: 0x1408) to the controller to inquire the length ofencryption key.After receiving this packet, the controller immediatelyreplies with a Command Completepacket (Event Code: 0x0e) to return theEncryption Key Size.2. In our fuzz test case, the timing of the controller's response to thispacket was delayed to an unexpected point: after the RFCOMM and L2CAPlayers had disconnected but before the HCI layer had disconnected.3. After receiving the Encryption Key Size Response at the time describedin point 2, the host still called the rfcomm_check_security function.However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`had already been released, and when the function executed`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.To fix this bug, check if `sk->sk_state` is BT_CLOSED before callingrfcomm_recv_frame in rfcomm_process_rx.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Reset IH OVERFLOW_CLEAR bitAllows us to detect subsequent IH ring buffer overflows as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing/trigger: Fix to return error if failed to alloc snapshotFix register_snapshot_trigger() to return error code if it failed toallocate a snapshot instead of 0 (success). Unless that, it will registersnapshot trigger without an error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: validate the parameters of bo mapping operations more clearlyVerify the parameters ofamdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in cifs_debug_files_proc_show()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix command flush on cable pullSystem crash due to command failed to flush back to SCSI layer. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0 ? __switch_to+0x10c/0x450 ? process_one_work+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201. ? worker_thread+0x1ce/0x390 ? create_worker+0x1a0/0x1a0 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8 ? set_kthread_struct+0x40/0x40 qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed. ? ret_from_fork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logoutThe system was under memory stress where driver was not able to allocate anSRB to carry out error recovery of cable pull. The failure to flush causesupper layer to start modifying scsi_cmnd. When the system frees up somememory, the subsequent cable pull trigger another command flush. At thispoint the driver access a null pointer when attempting to DMA unmap theSGL.Add a check to make sure commands are flush back on session tear down toprevent the null pointer access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface's parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected. As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete. But usb_deauthorize_interface() can't completeuntil the device lock has been released, and the lock won't bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun Reported by: xingwei lee
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add a dc_state NULL check in dc_state_release[How]Check wheather state is NULL before releasing it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: fix reference counting on zcrypt card objectsTests with hot-plugging crytpo cards on KVM guests with debugkernel build revealed an use after free for the load field ofthe struct zcrypt_card. The reason was an incorrect referencehandling of the zcrypt card object which could lead to a freeof the zcrypt card object while it was still in use.This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: fix UAF in direct writesIn production we have been hitting the following warning consistently------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]RIP: 0010:refcount_warn_saturate+0x9c/0xe0PKRU: 55555554Call Trace: ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30This is because we're completing the nfs_direct_request twice in a row.The source of this is when we have our commit requests to submit, weprocess them and send them off, and then in the completion path for thecommit requests we haveif (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);However since we're submitting asynchronous requests we sometimes haveone that completes before we submit the next one, so we end up callingcomplete on the nfs_direct_request twice.The only other place we use nfs_generic_commit_list() is in__nfs_commit_inode, which wraps this call in anfs_commit_begin();nfs_commit_end();Which is a common pattern for this style of completion handling, onethat is also repeated in the direct code with get_dreq()/put_dreq()calls around where we process events as well as in the completion paths.Fix this by using the same pattern for the commit requests.Before with my 200 node rocksdb stress running this warning would popevery 10ish minutes. With my patch the stress test has been running forseveral hours without popping.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-msm8974: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fat: fix uninitialized field in nostale filehandlesWhen fat_encode_fh_nostale() encodes file handle without a parent itstores only first 10 bytes of the file handle. However the length of thefile handle must be a multiple of 4 so the file handle is actually 12bytes long and the last two bytes remain uninitialized. This is notgreat at we potentially leak uninitialized information with the handleto userspace. Properly initialize the full handle length.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - resolve race condition during AER recoveryDuring the PCI AER system's error recovery process, the kernel drivermay encounter a race condition with freeing the reset_data structure'smemory. If the device restart will take more than 10 seconds the functionscheduling that restart will exit due to a timeout, and the reset_datastructure will be freed. However, this data structure is used forcompletion notification after the restart is completed, which leadsto a UAF bug.This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340To resolve this race condition, the memory associated to the containerof the work_struct is freed on the worker if the timeout expired,otherwise on the function that schedules the worker.The timeout detection can be done by checking if the caller isstill waiting for completion or not by using completion_done() function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Always flush async #PF workqueue when vCPU is being destroyedAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing itscompletion queue, e.g. when a VM and all its vCPUs is being destroyed.KVM must ensure that none of its workqueue callbacks is running when thelast reference to the KVM _module_ is put. Gifting a reference to theassociated VM prevents the workqueue callback from dereferencing freedvCPU/VM memory, but does not prevent the KVM module from being unloadedbefore the callback completes.Drop the misguided VM refcount gifting, as calling kvm_put_kvm() fromasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue willresult in deadlock. async_pf_execute() can't return until kvm_put_kvm()finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,then there's no need to gift async_pf_execute() a reference because allinvocations of async_pf_execute() will be forced to complete before thevCPU and its VM are destroyed/freed. And that in turn fixes the moduleunloading bug as __fput() won't do module_put() on the last vCPU referenceuntil the vCPU has been freed, e.g. if closing the vCPU file also puts thelast reference to the KVM module.Note that kvm_check_async_pf_completion() may also take the work item offthe completion queue and so also needs to flush the work queue, as thework will not be seen by kvm_clear_async_pf_completion_queue(). Waitingon the workqueue could theoretically delay a vCPU due to waiting for thework to complete, but that's a very, very small chance, and likely a verysmall delay. kvm_arch_async_page_present_queued() unconditionally makes anew request, i.e. will effectively delay entering the guest, so theremaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm);and mmput() can't drop the last reference to the page tables if the vCPU isstill alive, i.e. the vCPU won't get stuck tearing down page tables.Add a helper to do the flushing, specifically to deal with "wakeup all"work items, as they aren't actually work items, i.e. are never placed in aworkqueue. Trying to flush a bogus workqueue entry rightly makes__flush_work() complain (kudos to whoever added that sanity check).Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check the inode number is not the invalid value of zeroSyskiller has produced an out of bounds access in fill_meta_index().That out of bounds access is ultimately caused because the inodehas an inode number with the invalid value of zero, which was not checked.The reason this causes the out of bounds access is due to followingsequence of events:1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode numberis not zero when the inode is created and returns -EINVAL if it is.[phillip@squashfs.org.uk: whitespace fix]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau: fix instmem race condition around ptr storesRunning a lot of VK CTS in parallel against nouveau, once everyfew hours you might see something like this crash.BUG: kernel NULL pointer dereference, address: 0000000000000008PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1RSP: 0000:ffffac20c5857838 EFLAGS: 00010202RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001cR13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001cFS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]Adding any sort of useful debug usually makes it go away, so I handwrote the function in a line, and debugged the asm.Every so often pt->memory->ptrs is NULL. This ptrs ptr is set inthe nv50_instobj_acquire called from nvkm_kmap.If Thread A and Thread B both get to nv50_instobj_acquire aroundthe same time, and Thread A hits the refcount_set line, and inlockstep thread B succeeds at refcount_inc_not_zero, there is achance the ptrs value won't have been stored since refcount_setis unordered. Force a memory barrier here, I picked smp_mb, sincewe want it on all CPUs and it's write followed by a read.v2: use paired smp_rmb/smp_wmb.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix mirred deadlock on device recursionWhen the mirred action is used on a classful egress qdisc and a packet ismirrored or redirected to self we hit a qdisc lock deadlock.See trace below.[..... other info removed for brevity....][ 82.890906][ 82.890906] ============================================[ 82.890906] WARNING: possible recursive locking detected[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W[ 82.890906] --------------------------------------------[ 82.890906] ping/418 is trying to acquire lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] but task is already holding lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] other info that might help us debug this:[ 82.890906] Possible unsafe locking scenario:[ 82.890906][ 82.890906] CPU0[ 82.890906] ----[ 82.890906] lock(&sch->q.lock);[ 82.890906] lock(&sch->q.lock);[ 82.890906][ 82.890906] *** DEADLOCK ***[ 82.890906][..... other info removed for brevity....]Example setup (eth0->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0Another example(eth0->eth1->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1tc qdisc add dev eth1 root handle 1: htb default 30tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0We fix this by adding an owner field (CPU id) to struct Qdisc set afterroot qdisc is entered. When the softirq enters it a second time, if theqdisc owner is the same CPU, the packet is dropped to break the loop.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak in map from abort pathThe delete set command does not rely on the transaction object forelement removal, therefore, a combination of delete element + delete setfrom the abort path could result in restoring twice the refcount of themapping.Check for inactive element in the next generation for the delete elementcommand in the abort path, skip restoring state if next generation bithas been already cleared. This is similar to the activate logic usingthe set walk iterator.[ 6170.286929] ------------[ cut here ]------------[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287071] Modules linked in: [...][ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0[ 6170.287962] Call Trace:[ 6170.287967] [ 6170.287973] ? __warn+0x9f/0x1a0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.288104] ? handle_bug+0x3c/0x70[ 6170.288112] ? exc_invalid_op+0x17/0x40[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: limit printing rate when illegal packet received by tun devvhost_worker will call tun call backs to receive packets. If too manyillegal packets arrives, tun_do_read will keep dumping packet contents.When console is enabled, it will costs much more cpu time to dumppacket and soft lockup will be detected.net_ratelimit mechanism can be used to limit the dumping rate.PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS works are canceled using the `cancel_work_sync` function,which waits for the work to end if it has already started.However, while waiting for the work handler, the handler willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker's responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I------------------------------------------------------ethtool/386089 is trying to acquire lock:ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0but task is already holding lock:ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4eother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK ***3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]stack backtrace:CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()nft_unregister_obj() can concurrent with __nft_obj_type_get(),and there is not any protection when iterate over nf_tables_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()nft_unregister_expr() can concurrent with __nft_expr_type_get(),and there is not any protection when iterate over nf_tables_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfp: flower: handle acti_netdevs allocation failureThe kmalloc_array() in nfp_fl_lag_do_work() will return null, ifthe physical memory has run out. As a result, if we dereferencethe acti_netdevs, the null pointer dereference bugs will happen.This patch adds a check to judge whether allocation failure occurs.If it happens, the delayed work will be rescheduled and try again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/dasd: fix double module refcount decrementOnce the discipline is associated with the device, deleting the devicetakes care of decrementing the module's refcount. Doing it manually onthis error path causes refcount to artificially decrease on each errorwhile it should just stay the same.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: usb-storage: Prevent divide-by-0 error in isd200_ata_commandThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS valuesin the ATA ID information to calculate cylinder and head values whencreating a CDB for READ or WRITE commands. The calculation involvesdivision and modulus operations, which will cause a crash if either ofthese values is 0. While this never happens with a genuine device, itcould happen with a flawed or subversive emulation, as reported by thesyzbot fuzzer.Protect against this possibility by refusing to bind to the device ifeither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's IDinformation is 0. This requires isd200_Initialization() to return anegative error code when initialization fails; currently it alwaysreturns 0 (even when there is an error).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau: lock the client object tree.It appears the client object tree has no locking unless I've missedsomething else. Fix races around adding/removing client objects,mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4562.099544] Call Trace:[ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90[ 4562.099583] ? exc_general_protection+0x246/0x4a0[ 4562.099593] ? asm_exc_general_protection+0x26/0x30[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau][ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau][ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau][ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm][ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau][ 4562.100356] __do_fault+0x32/0x150[ 4562.100362] do_fault+0x7c/0x560[ 4562.100369] __handle_mm_fault+0x800/0xc10[ 4562.100382] handle_mm_fault+0x17c/0x3e0[ 4562.100388] do_user_addr_fault+0x208/0x860[ 4562.100395] exc_page_fault+0x7f/0x200[ 4562.100402] asm_exc_page_fault+0x26/0x30[ 4562.100412] RIP: 0033:0x9b9870[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 4562.100446] [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Remove useless locks in usbtv_video_free()Remove locks calls in usbtv_video_free() becauseare useless and may led to a deadlock as reported here:https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000Also remove usbtv_stop() call since it will be called whenunregistering the device.Before 'c838530d230b' this issue would only be noticed if youdisconnect while streaming and now it is noticeable even whendisconnecting while not streaming.[hverkuil: fix minor spelling mistake in log message]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ttpci: fix two memleaks in budget_av_attachWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attachshould free the resources it allocates, like the error-handling ofttpci_budget_init does. Besides, there are two fixme comment refers tosuch deallocations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: go7007: fix a memleak in go7007_load_encoderIn go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated withouta deallocation thereafter. After the following call chain:saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go)go is freed and thus bounce is leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: avoid stack overflow warnings with clangA previous patch worked around a KASAN issue in stv0367, now a similarproblem showed up with clang:drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)Rework the stv0367_writereg() function to be simpler and mark bothregister access functions as noinline_for_stack so the temporaryi2c_msg structures do not get duplicated on the stack when KASAN_STACKis enabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: fix some memleaks in tpg_allocIn tpg_alloc, resources should be deallocated in each and everyerror-handling paths, since they are allocated in for statements.Otherwise there would be memleaks because tpg_free is called only whentpg_alloc return 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix some memleaks in gssx_dec_option_arrayThe creds and oa->data need to be freed in the error-handling paths aftertheir allocation. So this patch add these deallocations in thecorresponding paths.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gtp: Fix Use-After-Free in gtp_dellinkSince call_rcu, which is called in the hlist_for_each_entry_rcu traversalof gtp_dellink, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeoutThere is a race condition between l2cap_chan_timeout() andl2cap_chan_del(). When we use l2cap_chan_del() to delete thechannel, the chan->conn will be set to null. But the conn couldbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().As a result the null pointer dereference bug will happen. TheKASAN report triggered by POC is shown below:[ 472.074580] ==================================================================[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7[ 472.075308][ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.075308] Workqueue: events l2cap_chan_timeout[ 472.075308] Call Trace:[ 472.075308] [ 472.075308] dump_stack_lvl+0x137/0x1a0[ 472.075308] print_report+0x101/0x250[ 472.075308] ? __virt_addr_valid+0x77/0x160[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_report+0x139/0x170[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_check_range+0x2c3/0x2e0[ 472.075308] mutex_lock+0x68/0xc0[ 472.075308] l2cap_chan_timeout+0x181/0x300[ 472.075308] process_one_work+0x5d2/0xe00[ 472.075308] worker_thread+0xe1d/0x1660[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] kthread+0x2b7/0x350[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork+0x4d/0x80[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork_asm+0x11/0x20[ 472.075308] [ 472.075308] ==================================================================[ 472.094860] Disabling lock debugging due to kernel taint[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158[ 472.096136] #PF: supervisor write access in kernel mode[ 472.096136] #PF: error_code(0x0002) - not-present page[ 472.096136] PGD 0 P4D 0[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.096136] Workqueue: events l2cap_chan_timeout[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0[ 472.096136] Call Trace:[ 472.096136] [ 472.096136] ? __die_body+0x8d/0xe0[ 472.096136] ? page_fault_oops+0x6b8/0x9a0[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0[ 472.096136] ? do_user_addr_fault+0x1027/0x1340[ 472.096136] ? _printk+0x7a/0xa0[ 472.096136] ? mutex_lock+0x68/0xc0[ 472.096136] ? add_taint+0x42/0xd0[ 472.096136] ? exc_page_fault+0x6a/0x1b0[ 472.096136] ? asm_exc_page_fault+0x26/0x30[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] ? mutex_lock+0x88/0xc0[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] l2cap_chan_timeo---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject iftype change with mesh ID changeIt's currently possible to change the mesh ID when theinterface isn't yet in mesh mode, at the same time aschanging it into mesh mode. This leads to an overwriteof data in the wdev->u union for the interface type itcurrently has, causing cfg80211_change_iface() to dowrong things when switching.We could probably allow setting an interface to meshwhile setting the mesh ID at the same time by doing adifferent order of operations here, but realisticallythere's no userspace that's going to do this, so justdisallow changes in iftype when setting mesh ID.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Stop parsing channels bits when all channels are found.If a usb audio device sets more bits than the amount of channelsit could write outside of the map array.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fpga: region: add owner module and take its refcountThe current implementation of the fpga region assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the regionduring programming if the parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_regionstruct and use it to take the module's refcount. Modify the functions forregistering a region to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the region as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a region without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga region.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute groupThe DisplayPort driver's sysfs nodes may be present to the userspace beforetypec_altmode_set_drvdata() completes in dp_altmode_probe. This means thata sysfs read can trigger a NULL pointer error by deferencing dp->hpd inhpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returnsNULL in those cases.Remove manual sysfs node creation in favor of adding attribute group asdefault for devices bound to the driver. The ATTRIBUTE_GROUPS() macro isnot used here otherwise the path to the sysfs nodes is no longer compliantwith the ABI.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()Do the cache flush of converted pages in svm_register_enc_region() beforedropping kvm->lock to fix use-after-free issues where region and/or itsarray of pages could be freed by a different task, e.g. if userspace has__unregister_enc_region_locked() already queued up for the region.Note, the "obvious" alternative of using local variables doesn't fullyresolve the bug, as region->pages is also dynamically allocated. I.e. theregion structure itself would be fine, but region->pages could be freed.Flushing multiple pages under kvm->lock is unfortunate, but the entireflow is a rare slow path, and the manual flush is only needed on CPUs thatlack coherency for encrypted memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid: really frozen sync_thread during suspend1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes().2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used.3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend().4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), thetest shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),and with previous fixes, the test won't hang there anymore, however, thetest will still fail and complain that ext4 is corrupted. And with thispatch, the test won't hang due to stop_sync_thread() or fail due to ext4is corrupted anymore. However, there is still a deadlock related todm-raid456 that will be fixed in following patches.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm snapshot: fix lockup in dm_exception_table_exitThere was reported lockup when we exit a snapshot with many exceptions.Fix this by adding "cond_resched" to the loop that frees the exceptions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: Always disable interrupts when taking cgr_locksmp_call_function_single disables IRQs when executing the callback. Toprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.This is already done by qman_update_cgr and qman_delete_cgr; fix theother lockers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix corruption during on-line resizeWe observed a corruption during on-line resize of a file system that islarger than 16 TiB with 4k block size. With having more then 2^32 blocksresize_inode is turned off by default by mke2fs. The issue can bereproduced on a smaller file system for convenience by explicitlyturning off resize_inode. An on-line resize across an 8 GiB boundary (thesize of a meta block group in this setup) then leads to a corruption: dev=/dev/ # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks perblock group and 2^6 are the number of block groups that make a metablock group.The last checksum might be different depending on how the file is laidout across the physical blocks. The actual corruption occurs at physicalblock 63*2^15 = 2064384 which would be the location of the backup of themeta block group's block descriptor. During the on-line resize the filesystem will be converted to meta_bg starting at s_first_meta_bg which is2 in the example - meaning all block groups after 16 GiB. However, inext4_flex_group_add we might add block groups that are not part of thefirst meta block group yet. In the reproducer we achieved this bysubstracting the size of a whole block group from the point where themeta block group would start. This must be considered when updating thebackup block group descriptors to follow the non-meta_bg layout. The fixis to add a test whether the group to add is already part of the metablock group or not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detachThis is the candidate patch of CVE-2023-47233 :https://nvd.nist.gov/vuln/detail/CVE-2023-47233In brcm80211 driver,it starts with the following invoking chainto start init a timeout worker:->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker);If we disconnect the USB by hotplug, it will callbrcmf_usb_disconnect to make cleanup. The invoking chain is :brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg);While the timeout woker may still be running. This will causea use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.Fix it by deleting the timer and canceling the worker inbrcmf_cfg80211_detach.[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: Use raw spinlock for cgr_locksmp_call_function always runs its callback in hard IRQ context, even onPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlockfor cgr_lock to ensure we aren't waiting on a sleeping task.Although this bug has existed for a while, it was not apparent untilcommit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")which invokes smp_call_function_single via qman_update_cgr_safe everytime a link goes up or down.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: Set page uptodate in the correct placePage cache reads are lockless, so setting the freshly allocated pageuptodate before we've overwritten it with the data it's supposed to havein it will allow a simultaneous reader to see old data. Move the callto SetPageUptodate into ubifs_write_end(), which is after we copied thenew data into the page.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()In the for statement of lbs_allocate_cmd_buffer(), if the allocation ofcmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs tobe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: tc358743: register v4l2 async device only after successful setupEnsure the device has been setup correctly before registering the v4l2async device, thus allowing userspace to access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix a double-free in arfs_create_groupsWhen `in` allocated by kvzalloc fails, arfs_create_groups will freeft->g and return an error. However, arfs_create_table, the only caller ofarfs_create_groups, will hold this error and call tomlx5e_destroy_flow_table, in which the ft->g will be freed again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: clear BM pool before initializationRegister value persist after booting the kernel usingkexec which results in kernel panic. Thus clear theBM pool registers before initialisation to fix the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Prevent double free on errorThe error handling path in its_vpe_irq_domain_alloc() causes a double freewhen its_vpe_init() fails after successfully allocating at least oneinterrupt. This happens because its_vpe_irq_domain_free() frees theinterrupts along with the area bitmap and the vprop_page andits_vpe_irq_domain_alloc() subsequently frees the area bitmap and thevprop_page again.Fix this by unconditionally invoking its_vpe_irq_domain_free() whichhandles all cases correctly and by removing the bitmap/vprop_page freeingfrom its_vpe_irq_domain_alloc().[ tglx: Massaged change log ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix information leak in btrfs_ioctl_logical_to_ino()Syzbot reported the following information leak for inbtrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000This happens, because we're copying a 'struct btrfs_data_container' backto user-space. This btrfs_data_container is allocated in'init_data_container()' via kvmalloc(), which does not zero-fill thememory.Fix this by using kvzalloc() which zeroes out the memory on allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_is_valid_oplock_break()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in cifs_stats_proc_write()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in smb2_reconnect_server()The UAF bug is due to smb2_reconnect_server() accessing a session thatis already being teared down by another thread that is executing__cifs_put_smb_ses(). This can happen when (a) the client hasconnection to the server but no session or (b) another thread ends upsetting @ses->ses_status again to something different thanSES_EXITING.To fix this, we need to make sure to unconditionally set@ses->ses_status to SES_EXITING and prevent any other threads fromsetting a new status while we're still tearing it down.The following can be reproduced by adding some delay to right afterthe ipc is freed in __cifs_put_smb_ses() - which will givesmb2_reconnect_server() worker a chance to run and then accessing@ses->ipc:kinit ...mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10[disconnect srv]ls /mnt/1 &>/dev/nullsleep 30kdestroy[reconnect srv]sleep 10umount /mnt/1...CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126general protection fault, probably for non-canonical address0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc3904/01/2014Workqueue: cifsiod smb2_reconnect_server [cifs]RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 adde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 757b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6bRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000FS: 0000000000000000(0000) GS:ffff888157c00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: fix VM_PAT handling in COW mappingsPAT handling won't do the right thing in COW mappings: the first PTE (or,in fact, all PTEs) can be replaced during write faults to point at anonfolios. Reliably recovering the correct PFN and cachemode usingfollow_phys() from PTEs will not work in COW mappings.Using follow_phys(), we might just get the address+protection of the anonfolio (which is very wrong), or fail on swap/nonswap entries, failingfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() andtrack_pfn_copy(), not properly calling free_pfn_range().In free_pfn_range(), we either wouldn't call memtype_free() or would callit with the wrong range, possibly leaking memory.To fix that, let's update follow_phys() to refuse returning anon folios,and fallback to using the stored PFN inside vma->vm_pgoff for COW mappingsif we run into that.We will now properly handle untrack_pfn() with COW mappings, where wedon't need the cachemode. We'll have to fail fork()->track_pfn_copy() ifthe first page was replaced by an anon folio, though: we'd have to storethe cachemode in the VMA to make this work, likely growing the VMA size.For now, lets keep it simple and let track_pfn_copy() just fail in thatcase: it would have failed in the past with swap/nonswap entries already,and it would have done the wrong thing with anon folios.Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():<--- C reproducer ---> #include #include #include #include int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; }<--- C reproducer --->On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring[ 301.552930] ------------[ cut here ]------------[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0[ 301.565725] PKRU: 55555554[ 301.565944] Call Trace:[ 301.566148] [ 301.566325] ? untrack_pfn+0xf4/0x100[ 301.566618] ? __warn+0x81/0x130[ 301.566876] ? untrack_pfn+0xf4/0x100[ 3---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: module: prevent NULL pointer dereference in vsnprintf()In of_modalias(), we can get passed the str and len parameters which wouldcause a kernel oops in vsnprintf() since it only allows passing a NULL ptrwhen the length is also 0. Also, we need to filter out the negative valuesof the len parameter as these will result in a really huge buffer sincesnprintf() takes size_t parameter while ours is ssize_t...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix infinite recursion in fib6_dump_done().syzkaller reported infinite recursive calls of fib6_dump_done() duringnetlink socket destruction. [1]From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and thenthe response was generated. The following recvmmsg() resumed the dumpfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() dueto the fault injection. [0] 12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next callof inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stoppedreceiving the response halfway through, and finally netlink_sock_destruct()called nlk_sk(sk)->cb.done().fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if itis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() bynlk_sk(sk)->cb.args[3], but it has the same function, not NULL, callingitself recursively and hitting the stack guard page.To avoid the issue, let's set the destructor after kzalloc().[0]:FAULT_INJECTION: forcing a failure.name failslab, interval 1, probability 0, space 0, times 0CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801) ___sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)[1]:BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)stack guard page: 0000 [#1] PREEMPT SMP KASANCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: events netlink_sock_destruct_workRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d980000 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <#DF> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix use-after-free bugs caused by ax25_ds_del_timerWhen the ax25 device is detaching, the ax25_dev_device_down()calls ax25_ds_del_timer() to cleanup the slave_timer. Whenthe timer handler is running, the ax25_ds_del_timer() thatcalls del_timer() in it will return directly. As a result,the use-after-free bugs could happen, one of the scenariosis shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout()ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USEIn order to mitigate bugs, when the device is detaching, usetimer_shutdown_sync() to stop the timer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbmod: prevent kernel-infoleaksyzbot found that tcf_skbmod_dump() was copying four bytesfrom kernel stack to user space [1].The issue here is that 'struct tc_skbmod' has a four bytes hole.We need to clear the structure before filling fields.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Prevent lock inversion deadlock in map delete elemsyzkaller started using corpuses where a BPF tracing program deleteselements from a sockmap/sockhash map. Because BPF tracing programs can beinvoked from any interrupt context, locks taken during a map_delete_elemoperation must be hardirq-safe. Otherwise a deadlock due to lock inversionis possible, as reported by lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); lock(&host->lock);Locks in sockmap are hardirq-unsafe by design. We expects elements to bedeleted from sockmap/sockhash only in task (normal) context with interruptsenabled, or in softirq context.Detect when map_delete_elem operation is invoked from a context which is_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with anerror.Note that map updates are not affected by this issue. BPF verifier does notallow updating sockmap/sockhash from a BPF tracing program today.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: validate user input for expected lengthI got multiple syzbot reports showing old bugs exposedby BPF after commit 20f2505fb436 ("bpf: Try to avoid kzallocin cgroup/{s,g}etsockopt")setsockopt() @optlen argument should be taken into accountbefore copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7aRIP: 0033:0x7fd22067dde9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7aThe buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)The buggy address belongs to the physical page:page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)page_type: 0xffffefff(slab)raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe corresponding netns has been dismantled.Fortunately Josef Bacik could trigger the issue more often,and could test a patch I wrote two years ago.When TCP sockets are closed, we call inet_csk_clear_xmit_timers()to 'stop' the timers.inet_csk_clear_xmit_timers() can be called from any context,including when socket lock is held.This is the reason it uses sk_stop_timer(), aka del_timer().This means that ongoing timers might finish much later.For user sockets, this is fine because each running timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare terminated before the kernel socket is released.Modules using kernel sockets close them in their netns exit()handler.Also add sock_not_owned_by_me() helper to get LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e ("net: rds: acquire refcount on TCP sockets")which attempted to solve the issue in rds only.(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)We probably can remove the check_net() tests fromtcp_out_of_resources() and __tcp_close() in the future.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Fix error cleanup path in nfsd_rename()Commit a8b0026847b8 ("rename(): avoid a deadlock in the case of parentshaving no common ancestor") added an error bail out path. However thispath does not drop the remount protection that has been acquired. Fixthe cleanup path to properly drop the remount protection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packetsyzbot reported the following uninit-value access issue [1][2]:nci_rx_work() parses and processes received packet. When the payloadlength is zero, each message type handler reads uninitialized payloadand KMSAN detects this issue. The receipt of a packet with a zero-sizepayload is considered unexpected, and therefore, such packets should besilently discarded.This patch resolved this issue by checking payload size before callingeach message type handler codes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbmon: prevent division by zero in fb_videomode_from_videomode()The expression htotal * vtotal can have a zero value onoverflow. It is necessary to prevent division by zero like infb_var_to_videomode().Found by Linux Verification Center (linuxtesting.org) with Svace.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: prevent division by zero in blk_rq_stat_sum()The expression dst->nr_samples + src->nr_samples mayhave zero value on overflow. It is necessary to adda check to avoid division by zero.Found by Linux Verification Center (linuxtesting.org) with Svace.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return anunsuccessful status. In such cases, the elsiocb is not issued, thecompletion is not called, and thus the elsiocb resource is leaked.Check return value after calling lpfc_sli4_resume_rpi() and conditionallyrelease the elsiocb resource.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: don't check if plane->state->fb == state->fbCurrently, when using non-blocking commits, we can see the followingkernel warning:[ 110.908514] ------------[ cut here ]------------[ 110.908529] refcount_t: underflow; use-after-free.[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0[ 110.909170] sp : ffffffc00913b9c0[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001[ 110.909434] Call trace:[ 110.909441] refcount_dec_not_one+0xb8/0xc0[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4][ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4][ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper][ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4][ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper][ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper][ 110.911716] drm_atomic_commit+0xb0/0xdc [drm][ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm][ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm][ 110.914091] drm_ioctl+0x24c/0x3b0 [drm][ 110.914850] __arm64_sys_ioctl+0x9c/0xd4[ 110.914873] invoke_syscall+0x4c/0x114[ 110.914897] el0_svc_common+0xd0/0x118[ 110.914917] do_el0_svc+0x38/0xd0[ 110.914936] el0_svc+0x30/0x8c[ 110.914958] el0t_64_sync_handler+0x84/0xf0[ 110.914979] el0t_64_sync+0x18c/0x190[ 110.914996] ---[ end trace 0000000000000000 ]---This happens because, although `prepare_fb` and `cleanup_fb` areperfectly balanced, we cannot guarantee consistency in the checkplane->state->fb == state->fb. This means that sometimes we can increasethe refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. Theopposite can also be true.In fact, the struct drm_plane .state shouldn't be accessed directlybut instead, the `drm_atomic_get_new_plane_state()` helper function shouldbe used. So, we could stick to this check, but using`drm_atomic_get_new_plane_state()`. But actually, this check is not re---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btintel: Fix null ptr deref in btintel_read_versionIf hci_cmd_sync_complete() is triggered and skb is NULL, thenhdev->req_skb is NULL, which will cause this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: send: handle path ref underflow in header iterate_inode_ref()Change BUG_ON to proper error handling if building the path bufferfails. The pointers are not printed so we don't accidentally leak kerneladdresses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,as it could be caused only by two impossible conditions:- at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1- after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dyndbg: fix old BUG_ON in >control parserFix a BUG_ON from 2009. Even if it looks "unreachable" (I didn'treally look), lets make sure by removing it, doing pr_err and return-EINVAL instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: Fix possible use-after-free issue on kprobe registrationWhen unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will takea time. `is_module_text_address()` and `__module_text_address()`works with MODULE_STATE_LIVE and MODULE_STATE_GOING.If we use `is_module_text_address()` and `__module_text_address()`separately, there is a chance that the first one is succeeded but thenext one is failed because module->state becomes MODULE_STATE_UNFORMEDbetween those operations.In `check_kprobe_address_safe()`, if the second `__module_text_address()`is failed, that is ignored because it expected a kernel_text address.But it may have failed simply because module->state has been changedto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modifynon-exist module text address (use-after-free).To fix this problem, we should not use separated `is_module_text_address()`and `__module_text_address()`, but use only `__module_text_address()`once and do `try_module_get(module)` which is only available withMODULE_STATE_LIVE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operationsCreate subvolume, create snapshot and delete subvolume all usebtrfs_subvolume_reserve_metadata() to reserve metadata for the changesdone to the parent subvolume's fs tree, which cannot be mediated in thenormal way via start_transaction. When quota groups (squota or qgroups)are enabled, this reserves qgroup metadata of type PREALLOC. Once theoperation is associated to a transaction, we convert PREALLOC toPERTRANS, which gets cleared in bulk at the end of the transaction.However, the error paths of these three operations were not implementingthis lifecycle correctly. They unconditionally converted the PREALLOC toPERTRANS in a generic cleanup step regardless of errors or whether theoperation was fully associated to a transaction or not. This resulted inerror paths occasionally converting this rsv to PERTRANS without callingrecord_root_in_trans successfully, which meant that unless that root gotrecorded in the transaction by some other thread, the end of thetransaction would not free that root's PERTRANS, leaking it. Ultimately,this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmountfor the leaked reservation.The fix is to ensure that every qgroup PREALLOC reservation observes thefollowing properties:1. any failure before record_root_in_trans is called successfully results in freeing the PREALLOC reservation.2. after record_root_in_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation.This patch enforces those properties on the three operations. Withoutit, generic/269 with squotas enabled at mkfs time would fail in ~5-10runs on my system. With this patch, it ran successfully 1000 times in arow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: Fix incorrect descriptor free behaviorENA has two types of TX queues:- queues which only process TX packets arriving from the network stack- queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructionsThe ena_free_tx_bufs() cycles through all descriptors in a TX queueand unmaps + frees every descriptor that hasn't been acknowledged yetby the device (uncompleted TX transactions).The function assumes that the processed TX queue is necessarily fromthe first category listed above and ends up using napi_consume_skb()for descriptors belonging to an XDP specific queue.This patch solves a bug in which, in case of a VF reset, thedescriptors aren't freed correctly, leading to crashes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Properly link new fs rules into the treePreviously, add_rule_fg would only add newly created rules from thehandle into the tree when they had a refcount of 1. On the other hand,create_flow_handle tries hard to find and reference already existingidentical rules instead of creating new ones.These two behaviors can result in a situation where create_flow_handle1) creates a new rule and references it, then2) in a subsequent step during the same handle creation references it again,resulting in a rule with a refcount of 2 that is not linked into thetree, will have a NULL parent and root and will result in a crash whenthe flow group is deleted because del_sw_hw_rule, invoked on ruledeletion, assumes node->parent is != NULL.This happened in the wild, due to another bug related to incorrecthandling of duplicate pkt_reformat ids, which lead to the code increate_flow_handle incorrectly referencing a just-added rule in the sameflow handle, resulting in the problem described above. Full details areat [1].This patch changes add_rule_fg to add new rules without parents intothe tree, properly initializing them and avoiding the crash. This makesit more consistent with how rules are added to an FTE increate_flow_handle.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: complete validation of user inputIn my recent commit, I missed that do_replace() handlersuse copy_from_sockptr() (which I fixed), followedby unsafe copy_from_sockptr_offset() calls.In all functions, we can perform the @optlen validationbefore even calling xt_alloc_table_info() with the followingcheck:if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix not validating setsockopt user inputCheck user input length before copying data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: Fix not validating setsockopt user inputsyzbot reported rfcomm_sock_setsockopt_old() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_oldnet/bluetooth/rfcomm/sock.c:632 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70net/bluetooth/rfcomm/sock.c:673Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix not validating setsockopt user inputsyzbot reported sco_sock_setsockopt() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90net/bluetooth/sco.c:893Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addrAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, itstill means hlist_for_each_entry_rcu can return an item that got removedfrom the list. The memory itself of such item is not freed thanks to RCUbut nothing guarantees the actual content of the memory is sane.In particular, the reference count can be zero. This can happen ifipv6_del_addr is called in parallel. ipv6_del_addr removes the entryfrom inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops allreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enoughtiming, this can happen:1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.2. Then, the whole ipv6_del_addr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled.3. ipv6_get_ifaddr continues and tries to increments the reference count (in6_ifa_hold).4. The rcu is unlocked and the entry is freed.5. The freed entry is returned.Prevent increasing of the reference count in such case. The namein6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.[ 41.506330] refcount_t: addition on 0; use-after-free.[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130[ 41.507413] Modules linked in: veth bridge stp llc[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 41.516799] Call Trace:[ 41.517037] [ 41.517249] ? __warn+0x7b/0x120[ 41.517535] ? refcount_warn_saturate+0xa5/0x130[ 41.517923] ? report_bug+0x164/0x190[ 41.518240] ? handle_bug+0x3d/0x70[ 41.518541] ? exc_invalid_op+0x17/0x70[ 41.520972] ? asm_exc_invalid_op+0x1a/0x20[ 41.521325] ? refcount_warn_saturate+0xa5/0x130[ 41.521708] ipv6_get_ifaddr+0xda/0xe0[ 41.522035] inet6_rtm_getaddr+0x342/0x3f0[ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10[ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0[ 41.523102] ? netlink_unicast+0x30f/0x390[ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10[ 41.523832] netlink_rcv_skb+0x53/0x100[ 41.524157] netlink_unicast+0x23b/0x390[ 41.524484] netlink_sendmsg+0x1f2/0x440[ 41.524826] __sys_sendto+0x1d8/0x1f0[ 41.525145] __x64_sys_sendto+0x1f/0x30[ 41.525467] do_syscall_64+0xa5/0x1b0[ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a[ 41.526213] RIP: 0033:0x7fbc4cfcea9a[ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89[ 41.527942] RSP: 002b:00007f---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RINGsyzbot reported an illegal copy in xsk_setsockopt() [1]Make sure to validate setsockopt() @optlen parameter.[1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75RIP: 0033:0x7fb40587de69Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)The buggy address belongs to the physical page:page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6canon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)page_type: 0xffffffff()raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as allocatedpage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c:---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In 'hci_req_sync_complete()', always free the previous syncrequest state before assigning reference to a new one.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:raid1: fix use-after-free for original bio in raid1_write_request()r1_bio->bios[] is used to record new bios that will be issued tounderlying disks, however, in raid1_write_request(), r1_bio->bios[]will set to the original bio temporarily. Meanwhile, if blocked rdevis set, free_r1bio() will be called causing that all r1_bio->bios[]to be freed:raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL for (i = 0; i < disks; i++) -> for each rdev in conf // first rdev is normal r1_bio->bios[0] = bio; -> set to original bio // second rdev is blocked if (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> original bio is freedTest scripts:mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-cleanfio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ -iodepth=128 -name=test -direct=1echo blocked > /sys/block/md0/md/rd2/stateTest result:BUG bio-264 (Not tainted): Object already free-----------------------------------------------------------------------------Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e/0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 entry_SYSCALL_64_after_hwframe+0x6c/0x74Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_request+0xadf/0x1150 md_handle_request+0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0Since that bios for underlying disks are not allocated yet, fix thisproblem by using mempool_free() directly to free the r1_bio.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon top of batman-adv. In this case, at least 116 byte would be needed.There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)in the log but the function will never finish. Problem here is that thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.While this should be handled proactively when:* interface with too low MTU is added* VLAN is added* non-purgeable local mac is added* MTU of an attached interface is reduced* fragmentation setting gets disabled (which most likely requires dropping attached interfaces)not all of these scenarios can be prevented because batman-adv is onlyconsuming events without the the possibility to prevent these actions(non-purgable MAC address added, MTU of an attached interface is reduced).It is therefore necessary to also make sure that the code is able to handlealso the situations when there were already incompatible systemconfiguration are present.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-upThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.However, this is not necessary, because I2C core already has its ownlocking for that.More importantly, this flag can cause a lock-up: if the flag is set ini2c_hid_xfer() and an interrupt happens, the interrupt handler(i2c_hid_irq) will check this flag and return immediately without doinganything, then the interrupt handler will be invoked again in aninfinite loop.Since interrupt handler is an RT task, it takes over the CPU and theflag-clearing task never gets scheduled, thus we have a lock-up.Delete this unnecessary flag.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not use WQ_MEM_RECLAIM flag for workqueueIssue reported by customer during SRIOV testing, call trace:When both i40e and the i40iw driver are loaded, a warningin check_flush_dependency is being triggered. This seemsto be because of the i40e driver workqueue is allocated withthe WQ_MEM_RECLAIM flag, and the i40iw one is not.Similar error was encountered on ice too and it was fixed byremoving the flag. Do the same for i40e too.[Feb 9 09:08] ------------[ cut here ]------------[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] isflushing !WQ_MEM_RECLAIM infiniband:0x0[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966check_flush_dependency+0x10b/0x120[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seqsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtrrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdmaintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssifisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermalintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_coreiTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncoreioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ichintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_padxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbedrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intellibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirrordm_region_hash dm_log dm_mod fuse[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Nottainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOSSE5C620.86B.02.01.0013.121520200651 12/15/2020[ +0.000001] Workqueue: i40e i40e_service_task [i40e][ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 4881 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fdff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:0000000000000027[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:ffff94d47f620bc0[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:00000000ffff7fff[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:ffff94c5451ea180[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:ffff94c5f1330ab0[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)knlGS:0000000000000000[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:00000000007706f0[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[ +0.000001] PKRU: 55555554[ +0.000001] Call Trace:[ +0.000001] [ +0.000002] ? __warn+0x80/0x130[ +0.000003] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? report_bug+0x195/0x1a0[ +0.000005] ? handle_bug+0x3c/0x70[ +0.000003] ? exc_invalid_op+0x14/0x70[ +0.000002] ? asm_exc_invalid_op+0x16/0x20[ +0.000006] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? check_flush_dependency+0x10b/0x120[ +0.000002] __flush_workqueue+0x126/0x3f0[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core][ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core][ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core][ +0.000020] i40iw_close+0x4b/0x90 [irdma][ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e][ +0.000035] i40e_service_task+0x126/0x190 [i40e][ +0.000024] process_one_work+0x174/0x340[ +0.000003] worker_th---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()Extend a critical section to prevent chan from early freeing.Also make the l2cap_connect() return type void. Nothing is using thereturned value but it is ugly to return a potentially freed pointer.Making it void will help with backports because earlier kernels did usethe return value. Now the compile will break for kernels where thispatch is not a complete fix.Call stack summary:[use]l2cap_bredr_sig_cmd l2cap_connect mutex_lock(&conn->chan_lock); | chan = pchan->ops->new_connection(pchan); <- alloc chan | __l2cap_chan_add(conn, chan); | l2cap_chan_hold(chan); | list_add(&chan->list, &conn->chan_l); ... (1) mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free[free]l2cap_conn_del mutex_lock(&conn->chan_lock);| foreach chan in conn->chan_l: ... (2)| l2cap_chan_put(chan);| l2cap_chan_destroy| kfree(chan) ... (3) <- chan freed mutex_unlock(&conn->chan_lock);==================================================================BUG: KASAN: slab-use-after-free in instrument_atomic_readinclude/linux/instrumented.h:68 [inline]BUG: KASAN: slab-use-after-free in _test_bitinclude/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0net/bluetooth/l2cap_core.c:4260Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/arm/malidp: fix a possible null pointer dereferenceIn malidp_mw_connector_reset, new memory is allocated with kzalloc, butno check is performed. In order to prevent null pointer dereferencing,ensure that mw_state is checked before calling__drm_atomic_helper_connector_reset.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppdev: Add an error check in register_deviceIn register_device, the return value of ida_simple_get is unchecked,in witch ida_simple_get will use an invalid index value.To address this issue, index should be checked after ida_simple_get. Whenthe index value is abnormal, a warning message should be printed, the portshould be dropped, and the value should be recorded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sdhci-msm: pervent access to suspended controllerGeneric sdhci code registers LED device and uses host->runtime_suspendedflag to protect access to it. The sdhci-msm driver doesn't set this flag,which causes a crash when LED is accessed while controller is runtimesuspended. Fix this by setting the flag correctly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: tproxy: bail out if IP has been disabled on the devicesyzbot reports:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f][..]RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168__in_dev_get_rcu() can return NULL, so check for this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix loop termination condition in gss_free_in_token_pages()The in_token->pages[] array is not NULL terminated. This results inthe following KASAN splat: KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fpga: bridge: add owner module and take its refcountThe current implementation of the fpga bridge assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the bridge ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_bridgestruct and use it to take the module's refcount. Modify the function forregistering a bridge to take an additional owner module parameter andrename it to avoid conflicts. Use the old function name for a helper macrothat automatically sets the module that registers the bridge as the owner.This ensures compatibility with existing low-level control modules andreduces the chances of registering a bridge without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga bridge.Other changes: opportunistically move put_device() from __fpga_bridge_get()to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity sincethe bridge device is taken in these functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent NULL dereference in ip6_output()According to syzbot, there is a chance that ip6_dst_idev()returns NULL in ip6_output(). Most places in IPv6 stackdeal with a NULL idev just fine, but not here.syzbot reported:general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ffRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fadR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()syzbot is able to trigger the following crash [1],caused by unsafe ip6_dst_idev() use.Indeed ip6_dst_idev() can return NULL, and must always be checked.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4cRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bdR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encryptedIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus ring buffer code could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the structvmbus_gpadl for the ring buffers to decide whether to free the memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bnx2fc: Remove spin_lock_bh while releasing resources after uploadThe session resources are used by FW and driver when session is offloaded,once session is uploaded these resources are not used. The lock is notrequired as these fields won't be used any longer. The offload and uploadcalls are sequential, hence lock is not required.This will suppress following BUG_ON():[ 449.843143] ------------[ cut here ]------------[ 449.848302] kernel BUG at mm/vmalloc.c:2727![ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1Rebooting.[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc][ 449.882910] RIP: 0010:vunmap+0x2e/0x30[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 449.993028] Call Trace:[ 449.995756] __iommu_dma_free+0x96/0x100[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc][ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc][ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc][ 450.018136] fc_rport_work+0x103/0x5b0 [libfc][ 450.023103] process_one_work+0x1e8/0x3c0[ 450.027581] worker_thread+0x50/0x3b0[ 450.031669] ? rescuer_thread+0x370/0x370[ 450.036143] kthread+0x149/0x170[ 450.039744] ? set_kthread_struct+0x40/0x40[ 450.044411] ret_from_fork+0x22/0x30[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Handle error of rpc_proc_register() in nfs_net_init().syzkaller reported a warning [0] triggered while destroying immaturenetns.rpc_proc_register() was called in init_nfs_fs(), but its errorhas been ignored since at least the initial commit 1da177e4c3f4("Linux-2.6.12-rc2").Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfsin net namespaces") converted the procfs to per-netns and madethe problem more visible.Even when rpc_proc_register() fails, nfs_net_init() could succeed,and thus nfs_net_exit() will be called while destroying the netns.Then, remove_proc_entry() will be called for non-existing procdirectory and trigger the warning below.Let's handle the error of rpc_proc_register() properly in nfs_net_init().[0]:name 'nfs'WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711Modules linked in:CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 ebRSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503cRDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffcR13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c/0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare+0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [inline] __se_sys_unshare kernel/fork.c:3391 [inline] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4eRIP: 0033:0x7f30d0febe5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5dRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: don't free NULL coalescing ruleIf the parsing fails, we can dereference a NULL pointer here.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Reapply "drm/qxl: simplify qxl_fence_wait"This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"and further debugging points to a possible circular locking dependencybetween the console_owner locking and the worker pool locking.Reverting the commit allows Steve's VM to boot to completion again.[ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firewire: ohci: mask bus reset interrupts between ISR and bottom halfIn the FireWire OHCI interrupt handler, if a bus reset interrupt hasoccurred, mask bus reset interrupts until bus_reset_work has serviced andcleared the interrupt.Normally, we always leave bus reset interrupts masked. We infer the busreset from the self-ID interrupt that happens shortly thereafter. Ascenario where we unmask bus reset interrupts was introduced in 2008 ina007bb857e0b26f5d8b73c2ff90782d9c0972620: IfOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, wewill unmask bus reset interrupts so we can log them.irq_handler logs the bus reset interrupt. However, we can't clear the busreset event flag in irq_handler, because we won't service the event untillater. irq_handler exits with the event flag still set. If thecorresponding interrupt is still unmasked, the first bus reset willusually freeze the system due to irq_handler being called again eachtime it exits. This freeze can be reproduced by loading firewire_ohciwith "modprobe firewire_ohci debug=-1" (to enable all debugging output).Apparently there are also some cases where bus_reset_work will get calledsoon enough to clear the event, and operation will continue normally.This freeze was first reported a few months after a007bb85 was committed,but until now it was never fixed. The debug level could safely be setto -1 through sysfs after the module was loaded, but this would beineffectual in logging bus reset interrupts since they were onlyunmasked during initialization.irq_handler will now leave the event flag set but mask bus resetinterrupts, so irq_handler won't be called again and there will be nofreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work willunmask the interrupt after servicing the event, so future interruptswill be caught as desired.As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now beenabled through sysfs in addition to during initial module loading.However, when enabled through sysfs, logging of bus reset interrupts willbe effective only starting with the second bus reset, afterbus_reset_work has executed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in:---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fpga: manager: add owner module and take its refcountThe current implementation of the fpga manager assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the manager ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_managerstruct and use it to take the module's refcount. Modify the functions forregistering the manager to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the manager as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a manager without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga manager.Other changes: opportunistically move put_device() from __fpga_mgr_get() tofpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since themanager device is taken in these functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Add 0 size check to mtk_drm_gem_objAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM objectof 0 bytes. Currently, no such check exists and the kernel will panic ifa userspace application attempts to allocate a 0x0 GBM buffer.Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 andverifying that we now return EINVAL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Ensure the copied buf is NUL terminatedCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes fromuserspace to that buffer. Later, we use sscanf on this buffer but we don'tensure that the string is terminated inside the buffer, this can lead toOOB read when using sscanf. Fix this issue by using memdup_user_nul insteadof memdup_user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: add a proper sanity check for endpointsSyzkaller reports [1] hitting a warning which is caused by presenceof a wrong endpoint type at the URB sumbitting stage. While therewas a check for a specific 4th endpoint, since it can switch typesbetween bulk and interrupt, other endpoints are trusted implicitly.Similar warning is triggered in a couple of other syzbot issues [2].Fix the issue by doing a comprehensive check of all endpointstaking into account difference between high- and full-speedconfiguration.[1] Syzkaller report:...WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504...Call Trace: carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 [2] Related syzkaller crashes:
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix possible use-after-free issue in ftrace_location()KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79The root cause is that, in lookup_rec(), ftrace record of some addressis being searched in ftrace pages of some module, but those ftrace pagesat the same time is being freed in ftrace_release_mod() as thecorresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free!To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix possible dead-lock in nr_rt_ioctl()syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)[1]WARNING: possible circular locking dependency detected6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted------------------------------------------------------syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK ***1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Check whether the media is initializedThe member "uzonesize" of struct alauda_info will remain 0if alauda_init_media() fails, potentially causing divide errorsin alauda_read_data() and alauda_write_lba().- Add a member "media_initialized" to struct alauda_info.- Change a condition in alauda_check_media() to ensure the first initialization.- Add an error check for the return value of alauda_init_media().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: stk1160: fix bounds checking in stk1160_copy_video()The subtract in this condition is reversed. The ->length is the lengthof the buffer. The ->bytesused is how many bytes we have copied thusfar. When the condition is reversed that means the result of thesubtraction is always negative but since it's unsigned then the resultis a very high positive value. That means the overflow check is nevertrue.Additionally, the ->bytesused doesn't actually work for this purposebecause we're not writing to "buf->mem + buf->bytesused". Instead, themath to calculate the destination where we are writing is a bitinvolved. You calculate the number of full lines already written,multiply by two, skip a line if necessary so that we start on an oddnumbered line, and add the offset into the line.To fix this buffer overflow, just take the actual destination where weare writing, if the offset is already out of bounds print an error andreturn. Otherwise, write up to buf->length bytes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:stm class: Fix a double free in stm_register_device()The put_device(&stm->dev) call will trigger stm_device_release() whichfrees "stm" so the vfree(stm) on the next line is a double free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: fix potential memory leak in vfio_intx_enable()If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn't update the respective globalvariable and after insmod - rmmod - insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Lock port->lock when calling uart_handle_cts_change()uart_handle_cts_change() has to be called with port lock taken,Since we run it in a separate work, the lock may not be taken atthe time of running. Make sure that it's taken by explicitly doingthat. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ap: Fix crash in AP internal function modify_bitmap()A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oopsoccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.The fix is simple: use unsigned long values for the internal variables. Thecorrect checks are already in place in the function but a simple int forthe internal variables was used with the possibility to overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don't enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context") by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix uninit-value in p9_client_rpc()Syzbot with the help of KMSAN reported the following error:BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75If p9_check_errors() fails early in p9_client_rpc(), req->rc.tagwill not be properly initialized. However, trace_9p_client_res()ends up trying to print it out anyway before p9_client_rpc()finishes.Fix this issue by assigning default values to p9_fcall fieldssuch as 'tag' and (just in case KMSAN unearths something new) 'id'during the tag allocation stage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: savage: Handle err return when savagefb_check_var failedThe commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")checks the value of pixclock to avoid divide-by-zero error. Howeverthe function savagefb_probe doesn't handle the error return ofsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRYWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytesto bug_table entries, and as a result the last entry in a bug table willbe ignored, potentially leading to an unexpected panic(). All priorentries in the table will be handled correctly.The arm64 ABI requires that struct fields of up to 8 bytes arenaturally-aligned, with padding added within a struct such that structare suitably aligned within arrays.When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes }... with 12 bytes total, requiring 4-byte alignment.When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes }... with 8 bytes total, with 6 bytes of data and 2 bytes of trailingpadding, requiring 4-byte alginment.When we create a bug_entry in assembly, we align the start of the entryto 4 bytes, which implicitly handles padding for any prior entries.However, we do not align the end of the entry, and so whenCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing paddingbytes.For the main kernel image this is not a problem as find_bug() doesn'tdepend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug;However for modules, module_bug_finalize() depends on the trailingbytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);... and as the last bug_entry lacks the necessary padding bytes, this entrywill not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out;... which can lead to a kenrel panic due to an unhandled bug.This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL");... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vmci: prevent speculation leaks by sanitizing event in event_deliver()Coverity spotted that event_msg is controlled by user-space,event_msg->event_data.event is passed to event_deliver() and usedas an index without sanitization.This change ensures that the event index is sanitized to mitigate anypossibility of speculative information leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.Only compile tested, no access to HW.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packetIn lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,but then it is unconditionally passed to skb_add_rx_frag() which looksstrange and could lead to null pointer dereference.lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)In this path there is no code which sets pg_info->page to NULL.So this check looks unneeded and doesn't solve potential problem.But I guess the author had reason to add a check and I have no such cardand can't do real test.In addition, the code in the function liquidio_push_packet() inliquidio/lio_core.c does exactly the same.Based on this, I consider the most acceptable compromise solution toadjust this issue by moving skb_add_rx_frag() into conditional scope.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: remove unnecessary WARN_ON() in implement()Syzkaller hit a warning [1] in a call to implement() when tryingto write a value into a field of smaller size in an output report.Since implement() already has a warn message printed out with thehelp of hid_warn() and value in question gets trimmed with: ... value &= m; ...WARN_ON may be considered superfluous. Remove it to suppress futuresyzkaller triggers.[1]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863Modules linked in:CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863...Call Trace: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messagesThe syzbot fuzzer found that the interrupt-URB completion callback inthe cdc-wdm driver was taking too long, and the driver's immediateresubmission of interrupt URBs with -EPROTO status combined with thedummy-hcd emulation to cause a CPU lockup:cdc_wdm 1-1:1.0: nonzero urb status received: -71cdc_wdm 1-1:1.0: wdm_int_callback - 0 byteswatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idleModules linked in:irq event stamp: 73096hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline]hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline]softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Testing showed that the problem did not occur if the two errormessages -- the first two lines above -- were removed; apparently addingmaterial to the kernel log takes a surprisingly large amount of time.In any case, the best approach for preventing these lockups and toavoid spamming the log with thousands of error messages per second isto ratelimit the two dev_err() calls. Therefore we replace them withdev_err_ratelimited().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible race in __fib6_drop_pcpu_from()syzbot found a race in __fib6_drop_pcpu_from() [1]If compiler reads more than once (*ppcpu_rt),second read could read NULL, if another cpu clearsthe value in rt6_get_pcpu_route().Add a READ_ONCE() to prevent this race.Also add rcu_read_lock()/rcu_read_unlock() becausewe rely on RCU protection while dereferencing pcpu_rt.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48RSP: 0018:ffffc900040df070 EFLAGS: 00010206RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Lock wiphy in cfg80211_get_stationWiphy should be locked before calling rdev_get_station() (see lockdepassert in ieee80211_get_station()).This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)This happens because STA has time to disconnect and reconnect beforebatadv_v_elp_throughput_metric_update() delayed work gets scheduled. Inthis situation, ath10k_sta_state() can be in the middle of resettingarsta data when the work queue get chance to be scheduled and ends upaccessing it. Locking wiphy prevents that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock tosynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called fromsoftirq context. However using only spin_lock() to get sta->ps_lock inieee80211_sta_ps_deliver_wakeup() does not prevent softirq to executeon this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try totake this same lock ending in deadlock. Below is an example of rcu stallthat arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raiseon the same CPU that is holding the lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vmxnet3: disable rx data ring on dma allocation failureWhen vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base,the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not resetrq->data_ring.desc_size for the data ring that failed, which presumablycauses the hypervisor to reference it on packet reception.To fix this bug, rq->data_ring.desc_size needs to be set to 0 to tellthe hypervisor to disable this feature.[ 95.436876] kernel BUG at net/core/skbuff.c:207![ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1[ 95.441558] Hardware name: VMware, Inc. VMware VirtualPlatform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018[ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f[ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24[ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246[ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f[ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f[ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60[ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000[ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0[ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000[ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0[ 95.459791] Call Trace:[ 95.460515] [ 95.461180] ? __die_body.cold+0x19/0x27[ 95.462150] ? die+0x2e/0x50[ 95.462976] ? do_trap+0xca/0x110[ 95.463973] ? do_error_trap+0x6a/0x90[ 95.464966] ? skb_panic+0x4d/0x4f[ 95.465901] ? exc_invalid_op+0x50/0x70[ 95.466849] ? skb_panic+0x4d/0x4f[ 95.467718] ? asm_exc_invalid_op+0x1a/0x20[ 95.468758] ? skb_panic+0x4d/0x4f[ 95.469655] skb_put.cold+0x10/0x10[ 95.470573] vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3][ 95.471853] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3][ 95.473185] __napi_poll+0x2b/0x160[ 95.474145] net_rx_action+0x2c6/0x3b0[ 95.475115] handle_softirqs+0xe7/0x2a0[ 95.476122] __irq_exit_rcu+0x97/0xb0[ 95.477109] common_interrupt+0x85/0xa0[ 95.478102] [ 95.478846] [ 95.479603] asm_common_interrupt+0x26/0x40[ 95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20[ 95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90[ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246[ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000[ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001[ 95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3[ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260[ 95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000[ 95.495035] acpi_safe_halt+0x14/0x20[ 95.496127] acpi_idle_do_entry+0x2f/0x50[ 95.497221] acpi_idle_enter+0x7f/0xd0[ 95.498272] cpuidle_enter_state+0x81/0x420[ 95.499375] cpuidle_enter+0x2d/0x40[ 95.500400] do_idle+0x1e5/0x240[ 95.501385] cpu_startup_entry+0x29/0x30[ 95.502422] start_secondary+0x11c/0x140[ 95.503454] common_startup_64+0x13e/0x141[ 95.504466] [ 95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsIn some versions of cfg80211, the ssids poinet might be a valid one eventhough n_ssids is 0. Accessing the pointer in this case will cuase anout-of-bound access. Fix this by checking n_ssids first.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't read past the mfuart notifcationIn case the firmware sends a notification that claims it has more datathan it has, we will read past that was allocated for the notification.Remove the print of the buffer, we won't see it by default. If needed,we can see the content with tracing.This was reported by KFENCE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: mesh: Fix leak of mesh_preq_queue objectsThe hwmp code use objects of type mesh_preq_queue, added to a list inieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpathgets deleted, ex mesh interface is removed, the entries in that list willnever get cleaned. Fix this by flushing all corresponding items of thepreq_queue in mesh_path_flush_pending().This should take care of KASAN reports like this:unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure theloads and stores are atomic. In the extremely unlikely scenario thecompiler tears the stores, it's theoretically possible for KVM to attemptto get a vCPU using an out-of-bounds index, e.g. if the write is splitinto multiple 8-bit stores, and is paired with a 32-bit load on a VM with257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff];As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00RSP: 0018:ffffc90000117378 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid"Info: mapping multiple BARs. Your kernel is fine.""). The initialpurpose of this commit was to stop memory mappings for operationregions from overlapping page boundaries, as it can trigger warningsif different page attributes are present.However, it was found that when this situation arises, mappingcontinues until the boundary's end, but there is still an attempt toread/write the entire length of the map, leading to a NULL pointerdeference. For example, if a four-byte mapping request is made butonly one byte is mapped because it hits the current page boundary'send, a four-byte read/write attempt is still made, resulting in a NULLpointer deference.Instead, map the entire length, as the ACPI specification does notmandate that it must be within the same page boundary. It ispermissible for it to be mapped across different regions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Add check for srq max_sge attributemax_sge attribute is passed by the user, and is inserted and usedunchecked, so verify that the value doesn't exceed maximum allowed valuebefore using it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()syzbot found hanging tasks waiting on rtnl_lock [1]A reproducer is available in the syzbot bug.When a request to add multiple actions with the same index is sent, thesecond request will block forever on the first request. This holdsrtnl_lock, and causes tasks to hang.Return -EAGAIN to prevent infinite looping, while keeping documentedbehavior.[1]INFO: task kworker/1:0:5088 blocked for more than 143 seconds.Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000Workqueue: events_power_efficient reg_check_chans_workCall Trace:context_switch kernel/sched/core.c:5409 [inline]__schedule+0xf15/0x5d00 kernel/sched/core.c:6746__schedule_loop kernel/sched/core.c:6823 [inline]schedule+0xe7/0x350 kernel/sched/core.c:6838schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895__mutex_lock_common kernel/locking/mutex.c:684 [inline]__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752wiphy_lock include/net/cfg80211.h:5953 [inline]reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()In the following concurrency we will access the uninitialized rs->lock:ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock hereand get the following dump_stack:=========================================================INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504[...]Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4][...]=========================================================Normally interval is 0 until s_msg_ratelimit_state is initialized, so___ratelimit() does nothing. But registering sysfs precedes initializingrs->lock, so it is possible to change rs->interval to a non-zero valuevia the msg_ratelimit_interval_ms interface of sysfs while rs->lock isuninitialized, and then a call to ext4_msg triggers the problem byaccessing an uninitialized rs->lock. Therefore register sysfs after allinitializations are complete to avoid such problems.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: add bounds checking to xlog_recover_process_dataThere is a lack of verification of the space occupied by fixed membersof xlog_op_header in the xlog_recover_process_data.We can create a crafted image to trigger an out of bounds read byfollowing these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crcFix:Add a check to make sure there is sufficient space to access fixed membersof xlog_op_header.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()xattr in ocfs2 maybe 'non-indexed', which saved with additional spacerequested. It's better to check if the memory is out of bound beforememcmp, although this possibility mainly comes from crafted poisonousimages.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptorSyzbot has identified a bug in usbcore (see the Closes: tag below)caused by our assumption that the reserved bits in an endpointdescriptor's bEndpointAddress field will always be 0. As a result ofthe bug, the endpoint_is_duplicate() routine in config.c (and possiblyother routines as well) may believe that two descriptors are fordistinct endpoints, even though they have the same direction andendpoint number. This can lead to confusion, including the bugidentified by syzbot (two descriptors with matching endpoint numbersand directions, where one was interrupt and the other was bulk).To fix the bug, we will clear the reserved bits in bEndpointAddresswhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1specs say these bits are "Reserved, reset to zero".) This requires usto make a copy of the descriptor earlier in usb_parse_endpoint() anduse the copy instead of the original when checking for duplicates.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: check bo_va->bo is non-NULL before using itThe call to radeon_vm_clear_freed might clear bo_va->bo, sowe have to check it before dereferencing it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn't mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let's make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ila: block BH in ila_output()As explained in commit 1378817486d6 ("tipc: block BHbefore using dst_cache"), net/core/dst_cache.chelpers need to be called with BH disabled.ila_output() is called from lwtunnel_output()possibly from process context, and under rcu_read_lock().We might be interrupted by a softirq, re-enter ila_output()and corrupt dst_cache data structures.Fix the race by using local_bh_disable().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fabrics: use reserved tag for reg read/write commandIn some scenarios, if too many commands are issued by nvme command inthe same time by user tasks, this may exhaust all tags of admin_q. Ifa reset (nvme reset or IO timeout) occurs before these commands finish,reconnect routine may fail to update nvme regs due to insufficient tags,which will cause kernel hang forever. In order to workaround this issue,maybe we can let reg_read32()/reg_read64()/reg_write32() use reservedtags. This maybe safe for nvmf:1. For the disable ctrl path, we will not issue connect command2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially.So the reserved tags may still be enough while reg_xx() use reserved tags.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modesIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().Add a check to avoid null pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modesIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix endpoint checking in cxacru_bind()Syzbot is still reporting quite an old issue [1] that occurs due toincomplete checking of present usb endpoints. As such, wrongendpoints types may be used at urb sumbitting stage which in turntriggers a warning in usb_submit_urb().Fix the issue by verifying that required endpoint types are presentfor both in and out endpoints, taking into account cmd endpoint type.Unfortunately, this patch has not been tested on real hardware.[1] Syzbot report:usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502...Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-core: Fix null pointer dereference on errorIf the ata_port_alloc() call in ata_host_alloc() fails,ata_host_release() will get called.However, the code in ata_host_release() tries to free ata_port structmembers unconditionally, which can lead to the following:BUG: unable to handle page fault for address: 0000000000003990PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]Do not access ata_port struct members unconditionally.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix DIO failure due to insufficient transaction creditsThe code in ocfs2_dio_end_io_write() estimates number of necessarytransaction credits using ocfs2_calc_extend_credits(). This however doesnot take into account that the IO could be arbitrarily large and cancontain arbitrary number of extents.Extent tree manipulations do often extend the current transaction but notin all of the cases. For example if we have only single block extents inthe tree, ocfs2_mark_extent_written() will end up callingocfs2_replace_extent_rec() all the time and we will never extend thecurrent transaction and eventually exhaust all the transaction credits ifthe IO contains many single block extents. Once that happens aWARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered injbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response tothis error. This was actually triggered by one of our customers on aheavily fragmented OCFS2 filesystem.To fix the issue make sure the transaction always has enough credits forone extent insert before each call of ocfs2_mark_extent_written().Heming Zhao said:------PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]#11 dio_complete at ffffffff8c2b9fa7#12 do_blockdev_direct_IO at ffffffff8c2bc09f#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]#14 generic_file_direct_write at ffffffff8c1dcf14#15 __generic_file_write_iter at ffffffff8c1dd07b#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]#17 aio_write at ffffffff8c2cc72e#18 kmem_cache_alloc at ffffffff8c248dde#19 do_io_submit at ffffffff8c2ccada#20 do_syscall_64 at ffffffff8c004984#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xdp: Remove WARN() from __xdp_reg_mem_model()syzkaller reports a warning in __xdp_reg_mem_model().The warning occurs only if __mem_id_init_hash_table() returns an error. Itreturns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly.The second case cannot happen since there is a static const rhashtable_paramsstruct with valid fields. So, warning is only triggered when there is aproblem with memory allocation.Thus, there is no sense in using WARN() to handle this error and it can besafely removed.WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75Found by Linux Verification Center (linuxtesting.org) with syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFERIn create_pinctrl(), pinctrl_maps_mutex is acquired before callingadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()calls pinctrl_free(). However, pinctrl_free() attempts to acquirepinctrl_maps_mutex, which is already held by create_pinctrl(), leading toa potential deadlock.This patch resolves the issue by releasing pinctrl_maps_mutex beforecalling pinctrl_free(), preventing the deadlock.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ecdh - explicitly zeroize private_keyprivate_key is overwritten with the key parameter passed in by thecaller (if present), or alternatively a newly generated private key.However, it is possible that the caller provides a key (or the newlygenerated key) which is shorter than the previous key. In thatscenario, some key material from the previous key would not beoverwritten. The easiest solution is to explicitly zeroize the entireprivate_key array first.Note that this patch slightly changes the behavior of this function:previously, if the ecc_gen_privkey failed, the old private_key wouldremain. Now, the private_key is always zeroized. This behavior isconsistent with the case where params.key is set and ecc_is_key_validfails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet_diag: Initialize pad field in struct inet_diag_req_v2KMSAN reported uninit-value access in raw_lookup() [1]. Diag for rawsockets uses the pad field in struct inet_diag_req_v2 for theunderlying protocol. This field corresponds to the sdiag_raw_protocolfield in struct inet_diag_req_raw.inet_diag_get_exact_compat() converts inet_diag_req toinet_diag_req_v2, but leaves the pad field uninitialized. So the issueoccurs when raw_lookup() accesses the sdiag_raw_protocol field.Fix this by initializing the pad field ininet_diag_get_exact_compat(). Also, do the same fix ininet_diag_dump_compat() to avoid the similar issue in the future.[1]BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()The following is emitted when using idxd (DSA) dmanegine as the datamover for ntb_transport that ntb_netdev uses.[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526[74412.556784] caller is netif_rx_internal+0x42/0x130[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024[74412.581699] Call Trace:[74412.584514] [74412.586933] dump_stack_lvl+0x55/0x70[74412.591129] check_preemption_disabled+0xc8/0xf0[74412.596374] netif_rx_internal+0x42/0x130[74412.600957] __netif_rx+0x20/0xd0[74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev][74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport][74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport][74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd][74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd][74412.634046] irq_thread_fn+0x21/0x60[74412.638134] ? irq_thread+0xa8/0x290[74412.642218] irq_thread+0x1a0/0x290[74412.646212] ? __pfx_irq_thread_fn+0x10/0x10[74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10[74412.656117] ? __pfx_irq_thread+0x10/0x10[74412.660686] kthread+0x100/0x130[74412.664384] ? __pfx_kthread+0x10/0x10[74412.668639] ret_from_fork+0x31/0x50[74412.672716] ? __pfx_kthread+0x10/0x10[74412.676978] ret_from_fork_asm+0x1a/0x30[74412.681457] The cause is due to the idxd driver interrupt completion handler usesthreaded interrupt and the threaded handler is not hard or soft interruptcontext. However __netif_rx() can only be called from interrupt context.Change the call to netif_rx() in order to allow completion via normalcontext for dmaengine drivers that utilize threaded irq handling.While the following commit changed from netif_rx() to __netif_rx(),baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),the change should've been a noop instead. However, the code precedes thisfix should've been using netif_rx_ni() or netif_rx_any_context().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM valuessyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUMto 2^31.We had a similar issue in sch_fq, fixed with commitd9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]Modules linked in:irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Workqueue: mld mld_ifc_workpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854sp : ffff800093d36700x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffffx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fcx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip finding free audio for unknown engine_id[WHY]ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, italso means it is uninitialized and does not need free audio.[HOW]Skip and return NULL.This fixes 2 OVERRUN issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check pipe offset before setting vblankpipe_ctx has a size of MAX_PIPES so checking its index before accessingthe array.This fixes an OVERRUN issue reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Make qedf_execute_tmf() non-preemptibleStop calling smp_processor_id() from preemptible code inqedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: avoid overflows in dirty throttling logicThe dirty throttling logic is interspersed with assumptions that dirtylimits in PAGE_SIZE units fit into 32-bit (so that various multiplicationsfit into 64-bits). If limits end up being larger, we will hit overflows,possible divisions by 0 etc. Fix these problems by never allowing solarge dirty limits as they have dubious practical value anyway. Fordirty_bytes / dirty_background_bytes interfaces we can just refuse to setso large limits. For dirty_ratio / dirty_background_ratio it isn't sosimple as the dirty limit is computed from the amount of available memorywhich can change due to memory hotplug etc. So when converting dirtylimits from ratios to numbers of pages, we just don't allow the result toexceed UINT_MAX.This is root-only triggerable problem which occurs when the operatorsets dirty limits to >16 TB.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnx2x: Fix multiple UBSAN array-index-out-of-boundsFix UBSAN warnings that occur when using a system with 32 physicalcpu cores or more, or when the user defines a number of Ethernetqueues greater than or equal to FP_SB_MAX_E1x using the num_queuesmodule parameter.Currently there is a read/write out of bounds that occurs on the array"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".Looking at the definition of the "struct stats_query_entry query" array:struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts andhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3meaning the array has a total size of 19.Since accesses to "struct stats_query_entry query" are offset-ted byBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernetqueues should not exceed FP_SB_MAX_E1x (16). However one of these queuesis reserved for FCOE and thus the number of Ethernet queues should be setto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) ifit is not.This is also described in a comment in the source code indrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definitionof FP_SB_MAX_E1x. Below is the part of this explanation that it importantfor this patch/* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */However this driver also supports NICs that use the E2 controller which canhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.Looking at the commits when the E2 support was added, it was originallyusing the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driverwas later updated to take full advantage of the E2 instead of having it belimited to the capabilities of the E1x. But as far as we can tell, thearray "stats_query_entry query" was still limited to using the FP-SBavailable to the E1x cards as part of an oversignt when the driver wasupdated to take full advantage of the E2, and now with the driver beingaware of the greater queue size supported by E2 NICs, it causes the UBSANwarnings seen in the stack traces below.This patch increases the size of the "stats_query_entry query" array byreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handleboth types of NICs.Stack traces:UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11index 20 is out of range for type 'stats_query_entry [19]'CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn't have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe sensitive data on failureWipe sensitive data from stack also if the copy_to_user() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsReplace memzero_explicit() and kfree() with kfree_sensitive() to fixwarnings reported by Coccinelle:WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: Account for stopped queues when reading NIC statsWe now account for the fact that the NIC might send us stats for asubset of queues. Without this change, gve_get_ethtool_stats might makean invalid access on the priv->stats_report->stats array.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: tda10048: Fix integer overflowstate->xtal_hz can be up to 16M, so it can overflow a 32 bit integerwhen multiplied by pll_mfactor.Create a new 64 bit variable to hold the calculations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIObusses") mv88e6xxx_default_mdio_bus() has checked that thereturn value of list_first_entry() is non-NULL.This appears to be intended to guard against the list chip->mdios beingempty. However, it is not the correct check as the implementation oflist_first_entry is not designed to return NULL for empty lists.Instead, use list_first_entry_or_null() which does return NULL if thelist is empty.Flagged by Smatch.Compile tested only.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/bhi: Avoid warning in #DB handler due to BHI mitigationWhen BHI mitigation is enabled, if SYSENTER is invoked with the TF flag setthen entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls theclear_bhb_loop() before the TF flag is cleared. This causes the #DB handler(exc_debug_kernel()) to issue a warning because single-step is used outside theentry_SYSENTER_compat() function.To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORYafter making sure the TF flag is cleared.The problem can be reproduced with the following sequence: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Segmentation fault (core dumped)The program is expected to crash, and the #DB handler will issue a warning.Kernel log: WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160 ... RIP: 0010:exc_debug_kernel+0xd2/0x160 ... Call Trace: <#DB> ? show_regs+0x68/0x80 ? __warn+0x8c/0x140 ? exc_debug_kernel+0xd2/0x160 ? report_bug+0x175/0x1a0 ? handle_bug+0x44/0x90 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? exc_debug_kernel+0xd2/0x160 exc_debug+0x43/0x50 asm_exc_debug+0x1e/0x40 RIP: 0010:clear_bhb_loop+0x0/0xb0 ... ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d [ bp: Massage commit message. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: mos7840: fix crash on resumeSince commit c49cfa917025 ("USB: serial: use generic method if noalternative is provided in usb serial layer"), USB serial core calls thegeneric resume implementation when the driver has not provided one.This can trigger a crash on resume with mos7840 since support formultiple read URBs was added back in 2011. Specifically, both port readURBs are now submitted on resume for open ports, but the context pointerof the second URB is left set to the core rather than mos7840 portstructure.Fix this by implementing dedicated suspend and resume functions formos7840.Tested with Delock 87414 USB 2.0 to 4x serial adapter.[ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socketWhen using a BPF program on kernel_connect(), the call can return -EPERM. Thiscauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causingthe kernel to potentially freeze up.Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.ECONNREFUSED as error seems reasonable. For programs setting a different errorcan be out of reach (see handling in 4fbac77d2d09) in particular on kernelswhich do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -errinstead of allow boolean"), thus given that it is better to simply remap forconsistent behavior. UDP does handle EPERM in xs_udp_send_request().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: Fix a use after free in hfcmulti_tx()Don't dereference *sp after calling dev_kfree_skb(*sp).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a segment issue when downgrading gso_sizeLinearize the skb when downgrading gso_size because it may trigger aBUG_ON() later when the skb is segmented as described in [1,2].
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Return non-zero value from tipc_udp_addr2str() on errortipc_udp_addr2str() should return non-zero value if the UDP mediaaddress is invalid. Otherwise, a buffer overflow access can occur intipc_media_addr_printf(). Fix this by returning 1 on an invalid UDPmedia address.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix a use-after-free related to destroying CM IDsiw_conn_req_handler() associates a new struct rdma_id_private (conn_id) withan existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Makesure that cm_work_handler() does not trigger a use-after-free by onlyfreeing of the struct rdma_id_private after all pending work has finished.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Complete command early within lockA crash was observed while performing NPIV and FW reset, BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]The command completion was done early while aborting the commands in driverunload path but outside lock to avoid the WARN_ON condition of performingdma_free_attr within the lock. However this caused race condition whilecommand completion via multiple paths causing system crash.Hence complete the command early in unload path but within the lock toavoid race condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix for possible memory corruptionInit Control Block is dereferenced incorrectly. Correctly dereference ICB
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: During vport delete send async logout explicitlyDuring vport delete, it is observed that during unload we hit a crashbecause of stale entries in outstanding command array. For all these staleI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) butI/Os could not complete while vport delete is in process of deleting. BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 Send out async logout explicitly for all the ports during vport delete.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: check dot and dotdot of dx_root before making dir indexedSyzbot reports a issue as follows:============================================BUG: unable to handle page fault for address: ffffed11022e24fePGD 23ffee067 P4D 23ffee067 PUD 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214[...]============================================The immediate cause of this problem is that there is only one valid dentryfor the block to be split during do_split, so split==0 results in out ofbounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295]The maximum length of a filename is 255 and the minimum block size is 1024,so it is always guaranteed that the number of entries is greater than orequal to 2 when do_split() is called.But syzbot's crafted image has no dot and dotdot in dir, and the dentrydistribution in dirblock is as follows: bus dentry1 hole dentry2 free|xx--|xx-------------|...............|xx-------------|...............|0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024So when renaming dentry1 increases its name_len length by 1, neither holenor free is sufficient to hold the new dentry, and make_indexed_dir() iscalled.In make_indexed_dir() it is assumed that the first two entries of thedirblock must be dot and dotdot, so bus and dentry1 are left in dx_rootbecause they are treated as dot and dotdot, and only dentry2 is movedto the new leaf block. That's why count is equal to 1.Therefore add the ext4_check_dx_root() helper function to add more sanitychecks to dot and dotdot before starting the conversion to avoid the aboveissue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid using corrupted block bitmap bufferWhen the filesystem block bitmap is corrupted, we detect the corruptionwhile loading the bitmap and fail the allocation with error. However thenext allocation from the same bitmap will notice the bitmap buffer isalready loaded and tries to allocate from the bitmap with mixed results(depending on the exact nature of the bitmap corruption). Fix theproblem by using BH_verified bit to indicate whether the bitmap is validor not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modesIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modesIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate(). Add a check to avoid npd.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: always initialize i_uid/i_gidAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()can safely skip setting them.Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values ofi_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid whenset_ownership() was not implemented. It also missed adjustingnet_ctl_set_ownership() to use the same default values in case thecomputation of a better value failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: properly dereference pe in ip_vs_add_serviceUse pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kvm: s390: Reject memory region operations for ucontrol VMsThis change rejects the KVM_SET_USER_MEMORY_REGION andKVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 andwould thus result in a null pointer dereference further in.Memory management needs to be performed in userspace and using theioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGIONand KVM_SET_USER_MEMORY_REGION2.[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Handle invalid decoder vsiHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsiis valid for future use.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ("net: Use nested-BH locking fornapi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it's running in NAPI contexteven when it's not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bna: adjust 'name' buf size of bna_tcb and bna_ccb structuresTo have enough space to write all possible sprintf() args. Currently'name' size is 16, but the first '%s' specifier may already need atleast 16 characters, since 'bnad->netdev->name' is used there.For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16And replace sprintf with snprintf.Detected using the static analysis tool - Svace.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup/cpuset: Prevent UAF in proc_cpuset_show()An UAF can happen when /proc/cpuset is read as reported in [1].This can be reproduced by the following methods:1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function.2.$cat /proc/
/cpuset repeatly.3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/$umount /sys/fs/cgroup/cpuset/ repeatly.The race that cause this bug can be shown as below:(umount) | (cat /proc//cpuset)css_release | proc_cpuset_showcss_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...);cgroup_destroy_root | mutex_lock(&cgroup_mutex);rebind_subsystems |cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..);When the cpuset is initialized, the root node top_cpuset.css.cgrpwill point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation willallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated&cgroup_root.cgrp. When the umount operation is executed,top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.The problem is that when rebinding to cgrp_dfl_root, there are caseswhere the cgroup_root allocated by setting up the root for cgroup v1is cached. This could lead to a Use-After-Free (UAF) if it issubsequently freed. The descendant cgroups of cgroup v1 can only befreed after the css is released. However, the css of the root will neverbe released, yet the cgroup_root should be freed when it is unmounted.This means that obtaining a reference to the css of the root doesnot guarantee that css.cgrp->root will not be freed.Fix this problem by using rcu_read_lock in proc_cpuset_show().As cgroup_root is kfree_rcu after commit d23b5c577715("cgroup: Make operations on the cgroup root_list RCU safe"),css->cgroup won't be freed during the critical section.To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe toreplace task_get_css with task_css.[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: initialize integrity buffer to zero before writing it to mediaMetadata added by bio_integrity_prep is using plain kmalloc, which leadsto random kernel memory being written media. For PI metadata this islimited to the app tag that isn't used by kernel generated metadata,but for non-PI metadata the entire buffer leaks kernel memory.Fix this by adding the __GFP_ZERO flag to allocations for writes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dma: fix call order in dmam_free_coherentdmam_free_coherent() frees a DMA allocation, which makes thefreed vaddr available for reuse, then calls devres_destroy()to remove and free the data structure used to track the DMAallocation. Between the two calls, it is possible for aconcurrent task to make an allocation with the same vaddrand add it to the devres list.If this happens, there will be two entries in the devres listwith the same vaddr and devres_destroy() can free the wrongentry, triggering the WARN_ON() in dmam_match.Fix by destroying the devres entry before freeing the DMAallocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a deadlock in dma buf fence pollingIntroduce a version of the fence ops that on release doesn't removethe fence from the pending list, and thus doesn't require a lock tofix poll->fence wait->fence unref deadlocks.vmwgfx overwrites the wait callback to iterate over the list of allfences and update their status, to do that it holds a lock to preventthe list modifcations from other threads. The fence destroy callbackboth deletes the fence and removes it from the list of pendingfences, for which it holds a lock.dma buf polling cb unrefs a fence after it's been signaled: so the pollcalls the wait, which signals the fences, which are being destroyed.The destruction tries to acquire the lock on the pending fences listwhich it can never get because it's held by the wait from which itwas called.Old bug, but not a lot of userspace apps were using dma-buf pollinginterfaces. Fix those, in particular this fixes KDE stalls/deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Always drain health in shutdown callbackThere is no point in recovery during device shutdown. if healthwork started need to wait for it to avoid races and NULL pointeraccess.Hence, drain health WQ on shutdown callback.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:devres: Fix memory leakage caused by driver API devm_free_percpu()It will cause memory leakage when use driver API devm_free_percpu()to free memory allocated by devm_alloc_percpu(), fixed by usingdevres_release() instead of devres_destroy() within devm_free_percpu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup under heavy CEQE loadCEQEs are handled in interrupt handler currently. This may cause theCPU core staying in interrupt context too long and lead to soft lockupunder heavy load.Handle CEQEs in BH workqueue and set an upper limit for the number ofCEQE handled by a single call of work handler.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled incfg80211_calculate_bitrate_he(), leading to below warning:kernel: invalid HE MCS: bw:6, ru:6kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Add error handling to pair_device()hci_conn_params_add() never checks for a NULL value and could lead to a NULLpointer dereference causing a crash.Fixed by adding error handling in the function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: core: check uartclk for zero to avoid divide by zeroCalling ioctl TIOCSSERIAL with an invalid baud_base canresult in uartclk being zero, which will result in adivide by zero error in uart_get_divisor(). The check foruartclk being zero in uart_set_info() needs to be donebefore other settings are made as subsequent calls toioctl TIOCSSERIAL for the same port would be impacted ifthe uartclk check was done where uartclk gets set.Oops: divide error: 0000 PREEMPT SMP KASAN PTIRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)Call Trace: serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers/tty/serial/8250/8250_port.c:2589)serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741)serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)uart_port_startup (drivers/tty/serial/serial_core.c:342)uart_startup (drivers/tty/serial/serial_core.c:368)uart_set_info (drivers/tty/serial/serial_core.c:1034)uart_set_info_user (drivers/tty/serial/serial_core.c:1059)tty_set_serial (drivers/tty/tty_io.c:2637)tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893)do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)Rule: add
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null pointer deref in dcn20_resource.cFixes a hang thats triggered when MPV is run on a DCN401 dGPU:mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=alland then enabling fullscreen playback (double click on the video)The following calltrace will be seen:[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 181.843997] #PF: supervisor instruction fetch in kernel mode[ 181.844003] #PF: error_code(0x0010) - not-present page[ 181.844009] PGD 0 P4D 0[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018[ 181.844044] RIP: 0010:0x0[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0[ 181.844141] Call Trace:[ 181.844146] [ 181.844153] ? show_regs+0x6d/0x80[ 181.844167] ? __die+0x24/0x80[ 181.844179] ? page_fault_oops+0x99/0x1b0[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0[ 181.844204] ? exc_page_fault+0x83/0x1b0[ 181.844216] ? asm_exc_page_fault+0x27/0x30[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu][ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu][ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu][ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu][ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu][ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null checker before passing variablesChecks null pointer before passing variables to functions.This fixes 3 NULL_RETURNS issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Fix the null pointer dereference for vega10_hwmgrCheck return value and conduct null pointer handling to avoid null pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rulesCheck the pointer value to fix potential null pointerdereference
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference for smu7optimize the code to avoid pass a null pointer (hwmgr->backend)to function smu7_update_edc_leakage_table.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: avoid BUG_ON() while continue reshape after reassemblingCurrently, mdadm support --revert-reshape to abort the reshape whilereassembling, as the test 07revert-grow. However, following BUG_ON()can be triggerred by the test:kernel BUG at drivers/md/raid5.c:6278!invalid opcode: 0000 [#1] PREEMPT SMP PTIirq event stamp: 158985CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94RIP: 0010:reshape_request+0x3f1/0xe60Call Trace: raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 Root cause is that --revert-reshape update the raid_disks from 5 to 4,while reshape position is still set, and after reassembling the array,reshape position will be read from super block, then during reshape thechecking of 'writepos' that is caculated by old reshape position willfail.Fix this panic the easy way first, by converting the BUG_ON() toWARN_ON(), and stop the reshape if checkings fail.Noted that mdadm must fix --revert-shape as well, and probably md/raidshould enhance metadata validation as well, however this meansreassemble will fail and there must be user tools to fix the wrongmetadata.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: prevent potential speculation leaks in gpio_device_get_desc()Userspace may trigger a speculative read of an address outside the gpiodescriptor array.Users can do that by calling gpio_ioctl() with an offset out of range.Offset is copied from user and then used as an array index to getthe gpio descriptor without sanitization in gpio_device_get_desc().This change ensures that the offset is sanitized by usingarray_index_nospec() to mitigate any possibility of speculativeinformation leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: Initialize beyond-EOF page contents before setting uptodatefuse_notify_store(), unlike fuse_do_readpage(), does not enable pagezeroing (because it can be used to change partial page contents).So fuse_notify_store() must be more careful to fully initialize pagecontents (including parts of the page that are beyond end-of-file)before marking the page uptodate.The current code can leave beyond-EOF page contents uninitialized, whichmakes these uninitialized page contents visible to userspace via mmap().This is an information leak, but only affects systems which do notenable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or thecorresponding kernel command line parameter).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mtrr: Check if fixed MTRRs exist before saving themMTRRs have an obsolete fixed variant for fine grained caching controlof the 640K-1MB region that uses separate MSRs. This fixed variant hasa separate capability bit in the MTRR capability MSR.So far all x86 CPUs which support MTRR have this separate bit set, so itwent unnoticed that mtrr_save_state() does not check the capability bitbefore accessing the fixed MTRR MSRs.Though on a CPU that does not support the fixed MTRR capability thisresults in a #GP. The #GP itself is harmless because the RDMSR fault ishandled gracefully, but results in a WARN_ON().Add the missing capability check to prevent this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: fix invalid FIFO access with special register setWhen enabling access to the special register set, Receiver time-out andRHR interrupts can happen. In this case, the IRQ handler will try to readfrom the FIFO thru the RHR register at address 0x00, but address 0x00 ismapped to DLL register, resulting in erroneous FIFO reading.Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register setFix the problem by claiming the efr_lock mutex when accessing the Specialregister set.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: Fix racy access to midibufThere can be concurrent accesses to line6 midibuf from both the URBcompletion callback and the rawmidi API access. This could be a causeof KMSAN warning triggered by syzkaller below (so put as reported-byhere).This patch protects the midibuf call of the former code path with aspinlock for avoiding the possible races.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/smt: Fix unbalance sched_smt_present dec/incI got the following warn report while doing stress test:jump label: negative count!WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),the cpu offline failed, but sched_smt_present is decremented beforecalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, sofix it by incrementing sched_smt_present in the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Prevent release of buffer in I/OWhen a task waiting for completion of a Store Data operation isinterrupted, an attempt is made to halt this operation. If this attemptfails due to a hardware or firmware problem, there is a chance that theSCLP facility might store data into buffers referenced by the originaloperation at a later time.Handle this situation by not releasing the referenced data buffers ifthe halt attempt fails. For current use cases, this might result in aleak of few pages of memory in case of a rare hardware/firmwaremalfunction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsIf the dpu_format_populate_layout() fails, then FB is prepared, but notcleaned up. This ends up leaking the pin_count on the GEM object andcauses a splat during DRM file closure:msm_obj->pin_countWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc[...]Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194irq event stamp: 129818hardirqs last enabled at (129817): [] console_unlock+0x118/0x124hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8csoftirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8softirqs last disabled at (129785): [] __do_softirq+0x14/0x20Patchwork: https://patchwork.freedesktop.org/patch/600714/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix a deadlock problem when config TC during resettingWhen config TC during the reset process, may cause a deadlock, the flow isas below: pf reset start | v ......setup tc | | v v DOWN: napi_disable()napi_disable()(skip) | | | v v ...... ...... | | v |napi_enable() | v UINIT: netif_napi_del() | v ...... | v INIT: netif_napi_add() | v ...... global reset start | | v v UP: napi_enable()(skip) ...... | | v v ...... napi_disable()In reset process, the driver will DOWN the port and then UINIT, in thiscase, the setup tc process will UP the port before UINIT, so cause theproblem. Adds a DOWN process in UINIT to fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: idt77252: prevent use after free in dequeue_rx()We can't dereference "skb" after calling vcc->push() because the skbis released.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: pull network headers in gtp_dev_xmit()syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]We must make sure the IPv4 or Ipv6 header is pulled in skb->headbefore accessing fields in them.Use pskb_inet_may_pull() to fix this issue.[1]BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: MT - limit max slotssyzbot is reporting too large allocation at input_mt_init_slots(), fornum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).Since nobody knows possible max slots, this patch chose 1024.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memcg_write_event_control(): fix a user-triggerable oopswe are *not* guaranteed that anything past the terminating NULis mapped (let alone initialized with anything sane).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix a potential NULL pointer dereferenceWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns aNULL pointer, but its callers only check for error pointers thus missthe NULL pointer case.Fix it by returning an error pointer with the error code carried fromsockfd_lookup().(I found this bug during code inspection.)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereference in pcs_get_function()pinmux_generic_get_function() can return NULL and the pointer 'function'was dereferenced without checking against NULL. Add checking of pointer'function' in pcs_get_function().Found by code review.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()This happens when called from SMB2_read() while using rdmaand reaching the rdma_readwrite_threshold.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don't bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don't do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3On a system with a GICv3, if a guest hasn't been configured withGICv3 and that the host is not capable of GICv2 emulation,a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.We therefore try to emulate the SGI access, only to hit a NULLpointer as no private interrupt is allocated (no GIC, remember?).The obvious fix is to give the guest what it deserves, in theshape of a UNDEF exception.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event->mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver: iio: add missing checks on iio_info's callback accessSome callbacks from iio_info structure are accessed without any check, soif a driver doesn't implement them trying to access the correspondingsysfs entries produce a kernel oops such as:[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute[...][ 2203.783416] Call trace:[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0[ 2203.830363] Code: bad PC value[ 2203.832695] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix possible NULL pointer dereferenceprofile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is madefrom __create_missing_ancestors(..) and 'ent->old' is NULL inaa_replace_profiles(..).In that case, it must return an error code and the code, -ENOENT representsits state that the path of its parent is not existed yet.BUG: kernel NULL pointer dereference, address: 0000000000000030PGD 0 P4D 0PREEMPT SMP PTICPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80RIP: 0033:0x7be9f211c574Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesasCR2: 0000000000000030---[ end trace 0000000000000000 ]---RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix mc_data out-of-bounds read warningClear warning that read mc_data[i-1] may out-of-bounds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix ucode out-of-bounds read warningClear warning that read ucode[] may out-of-bounds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_numberCheck the fb_channel_number range to avoid the array out-of-boundsread error
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix the Out-of-bounds read warningusing index i - 1U may beyond element indexfor mc_data[] when i = 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescindFor primary VM Bus channels, primary_channel pointer is always NULL. Thispointer is valid only for the secondary channels. Also, rescind callbackis meant for primary channels only.Fix NULL pointer dereference by retrieving the device_obj from the parentfor the primary channel.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: sanity check symbolic link sizeSyzkiller reports a "KMSAN: uninit-value in pick_link" bug.This is caused by an uninitialised page, which is ultimately causedby a corrupted symbolic link size read from disk.The reason why the corrupted symlink size causes an uninitialisedpage is due to the following sequence of events:1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.This patch adds a sanity check which checks that the symboliclink size is not larger than expected.--V2: fix spelling mistake.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - reject requests with unreasonable number of slotsWhen exercising uinput interface syzkaller may try setting up devicewith a really large number of slots, which causes memory allocationfailure in input_mt_init_slots(). While this allocation failure ishandled properly and request is rejected, it results in syzkallerreports. Additionally, such request may put undue burden on thesystem which will try to free a lot of memory for a bogus request.Fix it by limiting allowed number of slots to 100. This can easilybe extended if we see devices that can track more than 100 contacts.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,aborting the transaction and logging an error message.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BUG_ON() with error handling at update_ref_for_cow()Instead of a BUG_ON() just return an error, log an error message andabort the transaction in case we find an extent buffer belonging to therelocation tree that doesn't have the full backref flag set. This isunexpected and should never happen (save for bugs or a potential badmemory).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle errors from btrfs_dec_ref() properlyIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This isincorrect, we have proper error handling here, return the error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()mwifiex_get_priv_by_id() returns the priv pointer corresponding tothe bss_num and bss_type, but without checking if the priv is actuallycurrently in use.Unused priv pointers do not have a wiphy attached to them which canlead to NULL pointer dereferences further down the callstack. Fixthis by returning only used priv pointers which have priv->bss_modeset to something else than NL80211_IFTYPE_UNSPECIFIED.Said NULL pointer dereference happened when an Accesspoint was startedwith wpa_supplicant -i mlan0 with this config:network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678"}When waiting for the AP to be established, interrupting wpa_supplicantwith and starting it again this happens:| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140| Mem abort info:| ESR = 0x0000000096000004| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x04: level 0 translation fault| Data abort info:| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000| CM = 0, WnR = 0, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18| Hardware name: somemachine (DT)| Workqueue: events sdio_irq_work| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]| sp : ffff8000818b3a70| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000| Call trace:| mwifiex_get_cfp+0xd8/0x15c [mwifiex]| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]| mwifiex_process_event+0x110/0x238 [mwifiex]| mwifiex_main_process+0x428/0xa44 [mwifiex]| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]| process_sdio_pending_irqs+0x64/0x1b8| sdio_irq_work+0x4c/0x7c| process_one_work+0x148/0x2a0| worker_thread+0x2fc/0x40c| kthread+0x110/0x114| ret_from_fork+0x10/0x20| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)| ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pci/hotplug/pnv_php: Fix hotplug driver crash on PowernvThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernelcrash when we try to hot-unplug/disable the PCIe switch/bridge fromthe PHB.The crash occurs because although the MSI data structure has beenreleased during disable/hot-unplug path and it has been assignedwith NULL, still during unregistration the code was again trying toexplicitly disable the MSI which causes the NULL pointer dereference andkernel crash.The patch fixes the check during unregistration path to prevent invokingpci_disable_msi/msix() since its data structure is already freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add netif_device_attach/detach into PF reset flowEthtool callbacks can be executed while reset is in progress and try toaccess deleted resources, e.g. getting coalesce settings can result in aNULL pointer dereference seen below.Reproduction steps:Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net//device/resetwhen reset is in progress try to get coalesce settings using ethtool: # ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0Call Trace:ice_get_coalesce+0x17/0x30 [ice]coalesce_prepare_data+0x61/0x80ethnl_default_doit+0xde/0x340genl_family_rcv_msg_doit+0xf2/0x150genl_rcv_msg+0x1b3/0x2c0netlink_rcv_skb+0x5b/0x110genl_rcv+0x28/0x40netlink_unicast+0x19c/0x290netlink_sendmsg+0x222/0x490__sys_sendto+0x1df/0x1f0__x64_sys_sendto+0x24/0x30do_syscall_64+0x82/0x160entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7faee60d8e27Calling netif_device_detach() before reset makes the net core not callthe driver when ethtool command is issued, the attempt to execute anethtool command during reset will result in the following message: netlink error: No such deviceinstead of NULL pointer dereference. Once reset is done andice_rebuild() is executing, the netif_device_attach() is called to allowfor ethtool operations to occur again in a safe manner.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Remove proc entry when dev is unregistered.syzkaller reported a warning in bcm_connect() below. [0]The repro calls connect() to vxcan1, removes vxcan1, and callsconnect() with ifindex == 0.Calling connect() for a BCM socket allocates a proc entry.Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().However, removing the bound device resets bcm_sk(sk)->bound to 0in bcm_notify().The 2nd connect() tries to allocate a proc entry with the samename and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking theoriginal proc entry.Since the proc entry is available only for connect()ed sockets,let's clean up the entry when the bound netdev is unregistered.[0]:proc_dir_entry 'can-bcm/2456' already registeredWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375Modules linked in:CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ecFS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fbd708b0e5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5dRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()Smatch warns: arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential spectre issue 'args.args' [r] (local cap)The 'nargs' and 'nret' locals come directly from a user-suppliedbuffer and are used as indexes into a small stack-based array and asinputs to copy_to_user() after they are subject to bounds checks.Use array_index_nospec() after the bounds checks to clamp these valuesfor speculative execution.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid excessive partition lengthsAvoid mounting filesystems where the partition would overflow the32-bits used for block number. Also refuse to mount filesystems wherethe partition length is so large we cannot safely index bits in ablock bitmap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: fix return value of tcp_bpf_sendmsg()When we cork messages in psock->cork, the last message triggers theflushing will result in sending a sk_msg larger than the currentmessage size. In this case, in tcp_bpf_send_verdict(), 'copied' becomesnegative at least in the following case:468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta); // <==== HERE473 return -EACCES;Therefore, it could lead to the following BUG with a proper value of'copied' (thanks to syzbot). We should not use negative 'copied' as areturn value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanupCurrently napi_disable() gets called during rxq and txq cleanup,even before napi is enabled and hrtimer is initialized. It causeskernel panic.? page_fault_oops+0x136/0x2b0 ? page_counter_cancel+0x2e/0x80 ? do_user_addr_fault+0x2f2/0x640 ? refill_obj_stock+0xc4/0x110 ? exc_page_fault+0x71/0x160 ? asm_exc_page_fault+0x27/0x30 ? __mmdrop+0x10/0x180 ? __mmdrop+0xec/0x180 ? hrtimer_active+0xd/0x50 hrtimer_try_to_cancel+0x2c/0xf0 hrtimer_cancel+0x15/0x30 napi_disable+0x65/0x90 mana_destroy_rxq+0x4c/0x2f0 mana_create_rxq.isra.0+0x56c/0x6d0 ? mana_uncfg_vport+0x50/0x50 mana_alloc_queues+0x21b/0x320 ? skb_dequeue+0x5f/0x80
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix checks for huge PMDsPatch series "userfaultfd: fix races around pmd_trans_huge() check", v2.The pmd_trans_huge() code in mfill_atomic() is wrong in three differentways depending on kernel version:1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr().3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong.I decided to write two separate fixes for these (one fix for bugs 1+2, onefix for bug 3), so that the first fix can be backported to kernelsaffected by bugs 1+2.This patch (of 2):This fixes two issues.I discovered that the following race can occur: mfill_atomic other thread ============ ============
pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd))I have experimentally verified this in a kernel with extra mdelay() calls;the BUG_ON(pmd_none(*dst_pmd)) triggers.On kernels newer than commit 0d940a9b270b ("mm/pgtable: allowpte_offset_map[_lock]() to fail"), this can't lead to anything worse thana BUG_ON(), since the page table access helpers are actually designed todeal with page tables concurrently disappearing; but on older kernels(<=6.4), I think we could probably theoretically race past the twoBUG_ON() checks and end up treating a hugepage as a page table.The second issue is that, as Qi Zheng pointed out, there are other typesof huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs(in particular, migration PMDs).On <=6.4, this is worse than the first issue: If mfill_atomic() runs on aPMD that contains a migration entry (which just requires winning a single,fairly wide race), it will pass the PMD to pte_offset_map_lock(), whichassumes that the PMD points to a page table.Breakage follows: First, the kernel tries to take the PTE lock (which willcrash or maybe worse if there is no "struct page" for the address bits inthe migration entry PMD - I think at least on X86 there usually is nocorresponding "struct page" thanks to the PTE inversion mitigation, amd64looks different).If that didn't crash, the kernel would next try to write a PTE into whatit wrongly thinks is a page table.As part of fixing these issues, get rid of the check for pmd_trans_huge()before __pte_alloc() - that's redundant, we're going to have to check forthat after the __pte_alloc() anyway.Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch/netem: fix use after free in netem_dequeueIf netem_dequeue() enqueues packet to inner qdisc and that qdiscreturns __NET_XMIT_STOLEN. The packet is dropped butqdisc_tree_reduce_backlog() is not called to update the parent'sq.qlen, leading to the similar use-after-free as Commite04991a48dbaf382 ("netem: fix return value if duplicate enqueuefails")Commands to trigger KASAN UaF:ip link add type dummyip link set lo upip link set dummy0 uptc qdisc add dev lo parent root handle 1: drrtc filter add dev lo parent 1: basic classid 1:1tc class add dev lo classid 1:1 drrtc qdisc add dev lo parent 1:1 handle 2: netemtc qdisc add dev lo parent 2: handle 3: drrtc filter add dev lo parent 3: basic classid 3:1 action mirred egressredirect dev dummy0tc class add dev lo classid 3:1 drrping -c1 -W0.01 localhost # Trigger bugtc class del dev lo classid 1:1tc class add dev lo classid 1:1 drrping -c1 -W0.01 localhost # UaF
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: added NULL check at start of dc_validate_stream[Why]prevent invalid memory access[How]check if dc and stream are NULL
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check BIOS images before it is usedBIOS images may fail to load and null checks are added before they areused.This fixes 6 NULL_RETURNS issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entryIn a review discussion of the changes to support vCPU hotplug wherea check was added on the GICC being enabled if was online, it wasnoted that there is need to map back to the cpu and use that to indexinto a cpumask. As such, a valid ID is needed.If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possiblefor the entry in cpu_madt_gicc[cpu] == NULL. This function wouldthen cause a NULL pointer dereference. Whilst a path to triggerthis has not been established, harden this caller against thepossibility.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ELF: fix kernel.randomize_va_space double readELF loader uses "randomize_va_space" twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: fail closed if we can't get max channel used in indirection tablesCommit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count withactive RSS contexts") proves that allowing indirection table to containchannels with out of bounds IDs may lead to crashes. Currently themax channel check in the core gets skipped if driver can't fetchthe indirection table or when we can't allocate memory.Both of those conditions should be extremely rare but if they dohappen we should try to be safe and fail the channel change.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: clean up our handling of refs == 0 in snapshot deleteIn reada we BUG_ON(refs == 0), which could be unkind since we aren'tholding a lock on the extent leaf and thus could get a transientincorrect answer. In walk_down_proc we also BUG_ON(refs == 0), whichcould happen if we have extent tree corruption. Change that to return-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,however we return -EIO, which -EUCLEAN is a more appropriate error code.Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convertthat to proper error handling. Also adjust the error message so we canactually do something with the information.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()We handle errors here properly, ENOMEM isn't fatal, return the error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Limit the period on HaswellRunning the ltp test cve-2015-3290 concurrently reports the followingwarnings.perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330Thanks to Thomas Gleixner's analysis, the issue is caused by the lowinitial period (1) of the frequency estimation algorithm, which triggersthe defects of the HW, specifically erratum HSW11 and HSW143. (For thedetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)The HSW11 requires a period larger than 100 for the INST_RETIRED.ALLevent, but the initial period in the freq mode is 1. The erratum is thesame as the BDM11, which has been supported in the kernel. A minimumperiod of 128 is enforced as well on HSW.HSW143 is regarding that the fixed counter 1 may overcount 32 with theHyper-Threading is enabled. However, based on the test, the hardwarehas more issues than it tells. Besides the fixed counter 1, the message'interrupt took too long' can be observed on any counter which was armedwith a period < 32 and two events expired in the same NMI. A minimumperiod of 32 is enforced for the rest of the events.The recommended workaround code of the HSW143 is not implemented.Because it only addresses the issue for the fixed counter. It bringsextra overhead through extra MSR writing. No related overcounting issuehas been reported so far.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:spi: nxp-fspi: fix the KASAN report out-of-bounds bugChange the memcpy length to fix the out-of-bounds issue when writing thedata that is not 4 byte aligned to TX FIFO.To reproduce the issue, write 3 bytes data to NOR chip.dd if=3b of=/dev/mtd0[ 36.926103] ==================================================================[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455[ 36.946721][ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)[ 36.961260] Call trace:[ 36.963723] dump_backtrace+0x90/0xe8[ 36.967414] show_stack+0x18/0x24[ 36.970749] dump_stack_lvl+0x78/0x90[ 36.974451] print_report+0x114/0x5cc[ 36.978151] kasan_report+0xa4/0xf0[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838[ 36.990800] spi_mem_exec_op+0x8ec/0xd30[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0[ 36.999323] spi_mem_dirmap_write+0x238/0x32c[ 37.003710] spi_nor_write_data+0x220/0x374[ 37.007932] spi_nor_write+0x110/0x2e8[ 37.011711] mtd_write_oob_std+0x154/0x1f0[ 37.015838] mtd_write_oob+0x104/0x1d0[ 37.019617] mtd_write+0xb8/0x12c[ 37.022953] mtdchar_write+0x224/0x47c[ 37.026732] vfs_write+0x1e4/0x8c8[ 37.030163] ksys_write+0xec/0x1d0[ 37.033586] __arm64_sys_write+0x6c/0x9c[ 37.037539] invoke_syscall+0x6c/0x258[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c[ 37.046244] do_el0_svc+0x44/0x5c[ 37.049589] el0_svc+0x38/0x78[ 37.052681] el0t_64_sync_handler+0x13c/0x158[ 37.057077] el0t_64_sync+0x190/0x194[ 37.060775][ 37.062274] Allocated by task 455:[ 37.065701] kasan_save_stack+0x2c/0x54[ 37.069570] kasan_save_track+0x20/0x3c[ 37.073438] kasan_save_alloc_info+0x40/0x54[ 37.077736] __kasan_kmalloc+0xa0/0xb8[ 37.081515] __kmalloc_noprof+0x158/0x2f8[ 37.085563] mtd_kmalloc_up_to+0x120/0x154[ 37.089690] mtdchar_write+0x130/0x47c[ 37.093469] vfs_write+0x1e4/0x8c8[ 37.096901] ksys_write+0xec/0x1d0[ 37.100332] __arm64_sys_write+0x6c/0x9c[ 37.104287] invoke_syscall+0x6c/0x258[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c[ 37.112972] do_el0_svc+0x44/0x5c[ 37.116319] el0_svc+0x38/0x78[ 37.119401] el0t_64_sync_handler+0x13c/0x158[ 37.123788] el0t_64_sync+0x190/0x194[ 37.127474][ 37.128977] The buggy address belongs to the object at ffff00081037c2a0[ 37.128977] which belongs to the cache kmalloc-8 of size 8[ 37.141177] The buggy address is located 0 bytes inside of[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)[ 37.153465][ 37.154971] The buggy address belongs to the physical page:[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)[ 37.175149] page_type: 0xfdffffff(slab)[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000[ 37.194553] page dumped because: kasan: bad access detected[ 37.200144][ 37.201647] Memory state around the buggy address:[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc[ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc[ 37.228186] ^[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.246962] ==============================================================---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: panasonic-laptop: Fix SINF array out of bounds accessesThe panasonic laptop code in various places uses the SINF array with indexvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF arrayis big enough.Not all panasonic laptops have this many SINF array entries, for examplethe Toughbook CF-18 model only has 10 SINF array entries. So it onlysupports the AC+DC brightness entries and mute.Check that the SINF array has a minimum size which covers all AC+DCbrightness entries and refuse to load if the SINF array is smaller.For higher SINF indexes hide the sysfs attributes when the SINF arraydoes not contain an entry for that attribute, avoiding show()/store()accessing the array out of bounds and add bounds checking to the probe()and resume() code accessing these.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: fix initialization of grcThe grc must be initialize first. There can be a condition where iffou is NULL, goto out will be executed and grc would be useduninitialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy->enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late. After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_xattr_find_entry()Add a paranoia check to make sure it doesn't stray beyond valid memoryregion containing ocfs2 xattr entries when scanning for a match. It willprevent out-of-bound access in case of crafted images.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: change the order of rate limitsICMP messages are ratelimited :After the blamed commits, the two rate limiters are applied in this order:1) host wide ratelimit (icmp_global_allow())2) Per destination ratelimit (inetpeer based)In order to avoid side-channels attacks, we need to applythe per destination check first.This patch makes the following change :1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3)2) The per destination limit is checked/updated. This might add a new node in inetpeer tree.3) icmp_global_consume() consumes tokens if prior operations succeeded.This means that host wide ratelimit is still effectivein keeping inetpeer tree small even under DDOS.As a bonus, I removed icmp_global.lock as the fast pathcan use a lock-free operation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependencyIn the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related todestroying CM IDs"), the function flush_workqueue is invoked to flush thework queue iwcm_wq.But at that time, the work queue iwcm_wq was created via the functionalloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.Because the current process is trying to flush the whole iwcm_wq, ifiwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the currentprocess is not reclaiming memory or running on a workqueue which doesn'thave the flag WQ_MEM_RECLAIM as that can break forward-progress guaranteeleading to a deadlock.The call trace is as below:[ 125.350876][ T1430] Call Trace:[ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693)[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)[ 125.531837][ T1430] kthread (kernel/kthread.c:389)[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)[ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,as spotted by syzbot:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8cR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f1acc77def9Code: Unable to access opcode bytes at 0x7f1acc77decf.RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in:---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0R---truncated---
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().syzbot reported a warning in bcm_release(). [0]The blamed change fixed another warning that is triggered whenconnect() is issued again for a socket whose connect()ed device hasbeen unregistered.However, if the socket is just close()d without the 2nd connect(), theremaining bo->bcm_proc_read triggers unnecessary remove_proc_entry()in bcm_release().Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify().[0]name '4986'WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711Modules linked in:CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519aR10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fcfb51ee969Code: Unable to access opcode bytes at 0x7fcfb51ee93f.RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()Since '__dev_queue_xmit()' should be called with interrupts enabled,the following backtrace:ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)issues the warning (as reported by syzbot reproducer):WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120Fix this by implementing a two-phase skb reclamation in'ieee80211_do_stop()', where actual work is performedoutside of a section with interrupts disabled.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabledFix missuse of spin_lock_irq()/spin_unlock_irq() whenspin_lock_irqsave()/spin_lock_irqrestore() was hold.This was discovered through the lock debugging, and the correspondinglog is as follows:raw_local_irq_restore() called with IRQs enabledWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40...Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cxgb4: Added NULL check for lookup_atidThe lookup_atid() function can return NULL if the ATID isinvalid or does not exist in the identifier table, whichcould lead to dereferencing a null pointer without acheck in the `act_establish()` and `act_open_rpl()` functions.Add a NULL check to prevent null pointer dereferencing.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Clean up TPM space after command failuretpm_dev_transmit prepares the TPM space before attempting commandtransmission. However if the command fails no rollback of thispreparation is done. This can result in transient handles being leakedif the device is subsequently closed with no further commands performed.Fix this by flushing the space in the event of command transmissionfailure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodateWhen doing cleanup, if flags without OCFS2_BH_READAHEAD, it may triggerNULL pointer dereference in the following ocfs2_set_buffer_uptodate() ifbh is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: update orig_path in ext4_find_extent()In ext4_find_extent(), if the path is not big enough, we free it and set*orig_path to NULL. But after reallocating and successfully initializingthe path, we don't update *orig_path, in which case the caller gets avalid path but a NULL ppath, and this may cause a NULL pointer dereferenceor a path memory leak. For example:ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference!==================================================================BUG: kernel NULL pointer dereference, address: 0000000000000010CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847RIP: 0010:ext4_split_extent_at+0x6d/0x560Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0[...]==================================================================Therefore, *orig_path is updated when the extent lookup succeeds, so thatthe caller can safely use path or *ppath.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double brelse() the buffer of the extents pathIn ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has beenreleased, otherwise it may be released twice. An example of what triggersthis is as follows: split2 map split1|--------|-------|--------|ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twiceFinally got the following WARRNING when removing the buffer from lru:============================================VFS: brelse: Trying to free free bufferWARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716RIP: 0010:__brelse+0x58/0x90Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]============================================
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: aovid use-after-free in ext4_ext_insert_extent()As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path isreallocated in ext4_ext_create_new_leaf(), we'll use the stale path andcause UAF. Below is a sample trace with dummy values:ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr==================================================================BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800[...]Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]==================================================================So use *ppath to update the path to avoid the above problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix slab-use-after-free in ext4_split_extent_at()We hit the following use-after-free:==================================================================BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]==================================================================The flow of issue triggering is as follows:ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!!So when trying to zeroout or fix the extent length, call ext4_find_extent()to update the path.In addition we use *ppath directly as an ext4_ext_show_leaf() input toavoid possible use-after-free when EXT_DEBUG is defined, and to avoidunnecessary path updates.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: ensure the fw_info is not null before using itThis resolves the dereference null return value warningreported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata pathsWhen the HBA is undergoing a reset or is handling an errata event, NULL ptrdereference crashes may occur in routines such aslpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), orlpfc_abort_handler().Add NULL ptr checks before dereferencing hdwq pointers that may have beenfreed due to operations colliding with a reset or errata event handler.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check stream before comparing them[WHAT & HOW]amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It isnecessary to check for null before dereferencing them.This fixes 1 FORWARD_NULL issue reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrsThere are some cases, such as the one uncovered by Commit 46d4efcccc68("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")wheremsm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);is called on gpu->pdev == NULL, as the GPU device has not been fullyinitialized yet.Turns out that there's more than just the aforementioned path thatcauses this to happen (e.g. the case when there's speedbin data in thecatalog, but opp-supported-hw is missing in DT).Assigning msm_gpu->pdev earlier seems like the least painful solutionto this, therefore do so.Patchwork: https://patchwork.freedesktop.org/patch/602742/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before multiple uses[WHAT & HOW]Poniters, such as stream_enc and dc->bw_vbios, are null checked previouslyin the same function, so Coverity warns "implies that stream_enc anddc->bw_vbios might be null". They are used multiple times in thesubsequent code and need to be checked.This fixes 10 FORWARD_NULL issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before used[WHAT & HOW]Poniters, such as dc->clk_mgr, are null checked previously in the samefunction, so Coverity warns "implies that "dc->clk_mgr" might be null".As a result, these pointers need to be checked when used again.This fixes 10 FORWARD_NULL issues reported by Coverity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: avoid NULL pointer dereferenceiwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvstapointer is not NULL.It retrieves this pointer using iwl_mvm_sta_from_mac80211, which isdereferencing the ieee80211_sta pointer.If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULLpointer.Fix this by checking the sta pointer before retrieving the mvmstafrom it. If sta is not NULL, then mvmsta isn't either.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0
48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash> dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 : mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14]$66 = 0xffffffffcrash> px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash> sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash> px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ]
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmitSyzbot points out that skb_trim() has a sanity check on the existing length ofthe skb, which can be uninitialised in some error paths. The intent here isclearly just to reset the length to zero before resubmitting, so switch tocalling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()already contains a call to skb_reset_tail_pointer(), so remove the redundantcall.The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similarusage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_startIn sctp_listen_start() invoked by sctp_inet_listen(), it should set thesk_state back to CLOSED if sctp_autobind() fails due to whatever reason.Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuseis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash willbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hashis NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ncsi: Disable the ncsi work before freeing the associated structureThe work function can run after the ncsi device is freed, resultingin use-after-free bugs or kernel panic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious 'GSO' packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ("net: be more gentle about silly gsorequests coming from user") virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: counttransport header in UFO") while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb->lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size);Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix uaf in l2cap_connect[Syzbot reported]BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Workqueue: hci2 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244...Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prevent nf_skb_duplicated corruptionsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could writeper-cpu variable nf_skb_duplicated in an unsafe way [1].Disabling preemption as hinted by the splat is not enough,we have to disable soft interrupts as well.[1]BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f4ce4f7def9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()->jbd2_cleanup_journal_tail()->__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()->lock_buffer(journal->j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded. Additionally, use journal instead ofosb->journal directly to simplify the code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: reserve space for inline xattr before attaching reflink treeOne of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting,the fsck -fn output showed the below corruption[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,but fsck believes the largest valid value is 227. Clamp the next record value? nThe stat output from the debugfs.ocfs2 showed the following corruptionwhere the "Next Free Rec:" had overshot the "Count:" in the root metadatablock. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... .......The issue was in the reflink workfow while reserving space for inlinexattr. The problematic function is ocfs2_reflink_xattr_inline(). By thetime this function is called the reflink tree is already recreated at thedestination inode from the source inode. At this point, this functionreserves space for inline xattrs at the destination inode without evenchecking if there is space at the root metadata block. It simply reducesthe l_count from 243 to 227 thereby making space of 256 bytes for inlinexattr whereas the inode already has extents beyond this index (in thiscase up to 230), thereby causing corruption.The fix for this is to reserve space for inline metadata at the destinationinode before the reflink tree gets recreated. The customer has verified thefix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns errorIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()to recover some journal space. But if an error occurs while executingjbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for freespace right away, we try other branches, and if j_committing_transactionis NULL (i.e., the tid is 0), we will get the following complain:============================================JBD2: I/O error when updating journal superblock for sdd-8.__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available__jbd2_log_wait_for_space: no way to get more journal space in sdd-8------------[ cut here ]------------WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0Modules linked in:CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70[...]============================================So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing toclean up at the moment, continue to try to reclaim free space in other ways.Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corruptwhen updating journal superblock fails") to make jbd2_cleanup_journal_tailreturn the correct error code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ]
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: bcm2835: Fix timeout during suspend modeDuring noirq suspend phase the Raspberry Pi power driver suffer offirmware property timeouts. The reason is that the IRQ of the underlyingBCM2835 mailbox is disabled and rpi_firmware_property_list() will alwaysrun into a timeout [1].Since the VideoCore side isn't consider as a wakeup source, set theIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabledduring suspend-resume cycle.[1]PM: late suspend of devices complete after 1.754 msecsWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22cFirmware transaction 0x00028001 timeoutModules linked in:CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17Hardware name: BCM2835Call trace:unwind_backtrace from show_stack+0x18/0x1cshow_stack from dump_stack_lvl+0x34/0x44dump_stack_lvl from __warn+0x88/0xec__warn from warn_slowpath_fmt+0x7c/0xb0warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22crpi_firmware_property_list from rpi_firmware_property+0x68/0x8crpi_firmware_property from rpi_firmware_set_power+0x54/0xc0rpi_firmware_set_power from _genpd_power_off+0xe4/0x148_genpd_power_off from genpd_sync_power_off+0x7c/0x11cgenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0genpd_finish_suspend from dpm_run_callback+0x78/0xd0dpm_run_callback from device_suspend_noirq+0xc0/0x238device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5acsuspend_devices_and_enter from pm_suspend+0x254/0x2e4pm_suspend from state_store+0xa8/0xd4state_store from kernfs_fop_write_iter+0x154/0x1a0kernfs_fop_write_iter from vfs_write+0x12c/0x184vfs_write from ksys_write+0x78/0xc0ksys_write from ret_fast_syscall+0x0/0x54Exception stack(0xcc93dfa8 to 0xcc93dff0)[...]PM: noirq suspend of devices complete after 3095.584 msecs
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove unreasonable unlock in ocfs2_read_blocksPatch series "Misc fixes for ocfs2_read_blocks", v5.This series contains 2 fixes for ocfs2_read_blocks(). The first patch fixthe issue reported by syzbot, which detects bad unlock balance inocfs2_read_blocks(). The second patch fixes an issue reported by HemingZhao when reviewing above fix.This patch (of 2):There was a lock release before exiting, so remove the unreasonable unlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: cancel dqi_sync_work before freeing oinfoocfs2_global_read_info() will initialize and schedule dqi_sync_work at theend, if error occurs after successfully reading global quota, it willtrigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16cThis reports that there is an active delayed work when freeing oinfo inerror handling, so cancel dqi_sync_work first. BTW, return status insteadof -1 when .read_file_info fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: fix kernel info leak via "[uprobes]" vmaxol_add_vma() maps the uninitialized page allocated by __create_xol_area()into userspace. On some architectures (x86) this memory is readable evenwithout VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,although this doesn't really matter, debugger can read this memory anyway.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:aoe: fix the potential use-after-free problem in more placesFor fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potentialuse-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put()instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runsinto use-after-free.Then Nicolai Stange found more places in aoe have potential use-after-freeproblem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe()and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to pushpacket to tx queue. So they should also use dev_hold() to increase therefcnt of skb->dev.On the other hand, moving dev_put() to tx() causes that the refcnt ofskb->dev be reduced to a negative value, because correspondingdev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(),probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix integer overflow in BLKSECDISCARDI independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard()but for secure erase.Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r);will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix buffer overflow when parsing NFS reparse pointsReparseDataLength is sum of the InodeType size and DataBuffer size.So to get DataBuffer size it is needed to subtract InodeType's size fromReparseDataLength.Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBufferat position after the end of the buffer because it does not subtractInodeType size from the length. Fix this problem and correctly subtractvariable len.Member InodeType is present only when reparse buffer is large enough. Checkfor ReparseDataLength before accessing InodeType to prevent another invalidmemory access.Major and minor rdev values are present also only when reparse buffer islarge enough. Check for reparse buffer size before calling reparse_mkdev().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix an unsafe loop on the listThe kernel may crash when deleting a genetlink family if there are stilllisteners for that family:Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace:__netlink_clear_multicast_users+0x74/0xc0genl_unregister_family+0xd4/0x2d0Change the unsafe loop on the list to a safe one, because inside theloop there is an element removal from this list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slip: make slhc_remember() more robust against malicious packetssyzbot found that slhc_remember() was missing checks againstmalicious packets [1].slhc_remember() only checked the size of the packet was at least 20,which is not good enough.We need to make sure the packet includes the IPv4 and TCP headerthat are supposed to be carried.Add iph and th pointers to make the code more readable.[1]BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: do not delay dst_entries_add() in dst_release()dst_entries_add() uses per-cpu data that might be freed at netnsdismantle from ip6_route_net_exit() calling dst_entries_destroy()Before ip6_route_net_exit() can be called, we release allthe dsts associated with this netns, via calls to dst_release(),which waits an rcu grace period before calling dst_destroy()dst_entries_add() use in dst_destroy() is racy, becausedst_entries_destroy() could have been called already.Decrementing the number of dsts must happen sooner.Notes:1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this.2) There is also discussion about removing this count of dst, which might happen in future kernels.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: avoid NFPROTO_UNSPEC where neededsyzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packetprocessing. As this is only useful to restrict locally terminatingTCP/UDP traffic, register this for ipv4 and ipv6 family only.Pablo points out that this is a general issue, direct users of theset/getsockopt interface can call into targets/matches that were onlyintended for use with ip(6)tables.Check all UNSPEC matches and targets for similar issues:- matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area.- targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE.Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, asthey are provided for use by ip(6)tables.The MARK target is also used by arptables, so register for NFPROTO_ARP too.While at it, bail out if connbytes fails to enable the correspondingconntrack family.This change passes the selftests in iptables.git.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: accept TCA_STAB only for root qdiscMost qdiscs maintain their backlog using qdisc_pkt_len(skb)on the assumption it is invariant between the enqueue()and dequeue() handlers.Unfortunately syzbot can crash a host rather easily usinga TBF + SFQ combination, with an STAB on SFQ [1]We can't support TCA_STAB on arbitrary level, this wouldrequire to maintain per-qdisc storage.[1][ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 88.798611] #PF: supervisor read access in kernel mode[ 88.799014] #PF: error_code(0x0000) - not-present page[ 88.799506] PGD 0 P4D 0[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00All code======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ...Code starting with the faulting instruction=========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ...[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0[ 88.808165] Call Trace:[ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_changerfcomm_sk_state_change attempts to use sock_lock so it must never becalled with it locked but rfcomm_sock_ioctl always attempt to lock itcausing the following trace:======================================================WARNING: possible circular locking dependency detected6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted------------------------------------------------------syz-executor386/5093 is trying to acquire lock:ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73but task is already holding lock:ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: br_netfilter: fix panic with metadata_dst skbFix a kernel panic in the br_netfilter module when sending untaggedtraffic via a VxLAN device.This happens during the check for fragmentation in br_nf_dev_queue_xmit.It is dependent on:1) the br_netfilter module being loaded;2) net.bridge.bridge-nf-call-iptables set to 1;3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;4) untagged frames with size higher than the VxLAN MTU forwarded/floodedWhen forwarding the untagged packet to the VxLAN bridge port, beforethe netfilter hooks are called, br_handle_egress_vlan_tunnel is called andchanges the skb_dst to the tunnel dst. The tunnel_dst is a metadata typeof dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a checkfor frames that needs to be fragmented: frames with higher MTU than theVxLAN device end up calling br_nf_ip_fragment, which in turns callip_skb_dst_mtu.The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dstwith valid dst->dev, thus the crash.This case was never supported in the first place, so drop the packetinstead.PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.[ 176.291791] Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000110[ 176.292101] Mem abort info:[ 176.292184] ESR = 0x0000000096000004[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits[ 176.292530] SET = 0, FnV = 0[ 176.292709] EA = 0, S1PTW = 0[ 176.292862] FSC = 0x04: level 0 translation fault[ 176.293013] Data abort info:[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000[ 176.294166] [0000000000000110] pgd=0000000000000000,p4d=0000000000000000[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel vethbr_netfilter bridge stp llc ipv6 crct10dif_ce[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted6.8.0-rc3-g5b3fbd61b9d1 #2[ 176.296314] Hardware name: linux,dummy-virt (DT)[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBSBTYPE=--)[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter][ 176.297636] sp : ffff800080003630[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:ffff6828c49ad9f8[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:00000000000003e8[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:ffff6828c3b16d28[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:0000000000000014[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:0000000095744632[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:ffffb7e137926a70[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :0000000000000000[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :f20e0100bebafeca[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :0000000000000000[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :ffff6828c7f918f0[ 176.300889] Call trace:[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter][ 176.301703] nf_hook_slow+0x48/0x124[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge][ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter][ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter][ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter][ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter][ 176.303359] nf_hook_slow+0x48/0x124[ 176.303---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: bus: Fix double free in driver API bus_register()For bus_register(), any error which happens after kset_register() willcause that @priv are freed twice, fixed by setting @priv with NULL afterthe first free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: protect uart_port_dtr_rts() in uart_shutdown() tooCommit af224ca2df29 (serial: core: Prevent unsafe uart port access, part3) added few uport == NULL checks. It added one to uart_shutdown(), sothe commit assumes, uport can be NULL in there. But right after thatprotection, there is an unprotected "uart_port_dtr_rts(uport, false);"call. That is invoked only if HUPCL is set, so I assume that is thereason why we do not see lots of these reports.Or it cannot be NULL at this point at all for some reason :P.Until the above is investigated, stay on the safe side and move thisdereference to the if too.I got this inconsistency from Coverity under CID 1585130. Thanks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uprobe: avoid out-of-bounds memory access of fetching argsUprobe needs to fetch args into a percpu buffer, and then copy to ringbuffer to avoid non-atomic context problem.Sometimes user-space strings, arrays can be very large, but the size ofpercpu buffer is only page size. And store_trace_args() won't checkwhether these data exceeds a single page or not, caused out-of-boundsmemory access.It could be reproduced by following steps:1. build kernel with CONFIG_KASAN enabled2. save follow program as test.c```\#include \#include \#include // If string length large than MAX_STRING_SIZE, the fetch_store_strlen()// will return 0, cause __get_data_size() return shorter size, and// store_trace_args() will not trigger out-of-bounds access.// So make string length less than 4096.\#define STRLEN 4093void generate_string(char *str, int n){ int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0';}void print_string(char *str){ printf("%s\n", str);}int main(){ char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0;}```3. compile program`gcc -o test test.c`4. get the offset of `print_string()````objdump -t test | grep -w print_string0000000000401199 g F .text 000000000000001b print_string```5. configure uprobe with offset 0x1199```off=0x1199cd /sys/kernel/debug/tracing/echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_eventsecho 1 > events/uprobes/enableecho 1 > tracing_on```6. run `test`, and kasan will report error.==================================================================BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40RIP: 0033:0x401199Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ceRSP: 002b:00007ffdf00576a8 EFLAGS: 00000206RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 This commit enforces the buffer's maxlen less than a page-size to avoidstore_trace_args() out-of-memory access.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parport: Proper fix for array out-of-bounds accessThe recent fix for array out-of-bounds accesses replaced sprintf()calls blindly with snprintf(). However, since snprintf() returns thewould-be-printed size, not the actually output size, the lengthcalculation can still go over the given limit.Use scnprintf() instead of snprintf(), which returns the actuallyoutput letters, for addressing the potential out-of-bounds accessproperly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mad: Improve handling of timed out WRs of mad agentCurrent timeout handler of mad agent acquires/releases mad_agent_privlock for every timed out WRs. This causes heavy locking contentionwhen higher no. of WRs are to be handled inside timeout handler.This leads to softlockup with below trace in some use cases whererdma-cm path is used to establish connection between peer nodesTrace:----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRsand invoke send handler post creating the list. The new method acquires/releases lock once to fetch the list and hence helps to reduce lockingcontetiong when processing higher no. of WRs
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: probes: Remove broken LDR (literal) uprobe supportThe simulate_ldr_literal() and simulate_ldrsw_literal() functions areunsafe to use for uprobes. Both functions were originally written foruse with kprobes, and access memory with plain C accesses. When uprobeswas added, these were reused unmodified even though they cannot safelyaccess user memory.There are three key problems:1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()).2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN.3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers.Practically speaking, (1) and (2) are the big issues. Given there havebeen no reports of problems since the broken code was introduced, itappears that no-one is relying on probing these instructions withuprobes.Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW(literal), limiting the use of simulate_ldr_literal() andsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR(literal) and LDRSW (literal) will be rejected asarm_probe_decode_insn() will return INSN_REJECTED. In future we canconsider introducing working uprobes support for these instructions, butthis will require more significant work.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: fix potential memory leak in be_xmit()The be_xmit() returns NETDEV_TX_OK without freeing skbin case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: remove the incorrect Fw reference check when dirtying pagesWhen doing the direct-io reads it will also try to mark pages dirty,but for the read path it won't hold the Fw caps and there is casewill it get the Fw reference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Stop the active perfmon before being destroyedUpon closing the file descriptor, the active performance monitor is notstopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,the active performance monitor's pointer (`vc4->active_perfmon`) is stillretained.If we open a new file descriptor and submit a few jobs with performancemonitors, the driver will attempt to stop the active performance monitorusing the stale pointer in `vc4->active_perfmon`. However, this pointeris no longer valid because the previous process has already terminated,and all performance monitors associated with it have been destroyed andfreed.To fix this, when the active performance monitor belongs to a givenprocess, explicitly stop it before destroying and freeing it.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: probes: Fix uprobes for big-endian kernelsThe arm64 uprobes code is broken for big-endian kernels as it doesn'tconvert the in-memory instruction encoding (which is alwayslittle-endian) into the kernel's native endianness before analyzing andsimulating instructions. This may result in a few distinct problems:* The kernel may may erroneously reject probing an instruction which can safely be probed.* The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely.* The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding.The endianness mismatch isn't caught by the compiler or sparse because:* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness.* While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning.Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 andadding the appropriate __le32_to_cpu() conversions prior to consumingthe instruction encoding. The core uprobes copies these fields as opaqueranges of bytes, and so is unaffected by this change.At the same time, remove MAX_UINSN_BYTES and consistently useAARCH64_INSN_SIZE for clarity.Tested with the following:| #include
| #include || #define noinline __attribute__((noinline))|| static noinline void *adrp_self(void)| {| void *addr;|| asm volatile(| " adrp %x0, adrp_self\n"| " add %x0, %x0, :lo12:adrp_self\n"| : "=r" (addr));| }||| int main(int argc, char *argv)| {| void *ptr = adrp_self();| bool equal = (ptr == adrp_self);|| printf("adrp_self => %p\n"| "adrp_self() => %p\n"| "%s\n",| adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");|| return 0;| }.... where the adrp_self() function was compiled to:| 00000000004007e0 :| 4007e0: 90000000 adrp x0, 400000 <__ehdr_start>| 4007e4: 911f8000 add x0, x0, #0x7e0| 4007e8: d65f03c0 retBefore this patch, the ADRP is not recognized, and is assumed to besteppable, resulting in corruption of the result:| # ./adrp-self| adrp_self => 0x4007e0| adrp_self() => 0x4007e0| EQUAL| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events| # echo 1 > /sys/kernel/tracing/events/uprobes/enable| # ./adrp-self| adrp_self => 0x4007e0| adrp_self() => 0xffffffffff7e0| NOT EQUALAfter this patch, the ADRP is correctly recognized and simulated:| # ./adrp-self| adrp_self => 0x4007e0| adrp_self() => 0x4007e0| EQUAL| #| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events| # echo 1 > /sys/kernel/tracing/events/uprobes/enable| # ./adrp-self| adrp_self => 0x4007e0| adrp_self() => 0x4007e0| EQUAL
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-clock: Fix missing timespec64 check in pc_clock_settime()As Andrew pointed out, it will make sense that the PTP corechecked timespec64 struct's tv_sec and tv_nsec range before callingptp->info->settime64().As the man manual of clock_settime() said, if tp.tv_sec is negative ortp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,which include dynamic clocks which handles PTP clock, and the condition isconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()only check the timespec is valid, but not ensure that the time isin a valid range, so check it ahead using timespec64_valid_strict()in pc_clock_settime() and return -EINVAL if not valid.There are some drivers that use tp->tv_sec and tp->tv_nsec directly towrite registers without validity checks and assume that the higher layerhas checked it, which is dangerous and will benefit from this, such ashclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),and some drivers can remove the checks of itself.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/swapfile: skip HugeTLB pages for unuse_vmaI got a bad pud error and lost a 1GB HugeTLB when calling swapoff. Theproblem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)We can tell that pud_clear_bad is called by pud_none_or_clear_bad inunuse_pud_range() by ftrace. And therefore the HugeTLB pages will neverbe freed because we lost it from page table. We can skip HugeTLB pagesfor unuse_vma to fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid's fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid's fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the "ts" is not changedafter that.[pabeni@redhat.com: fixed commit message typo]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: refactor inode_bmap() to handle errorRefactor inode_bmap() to handle error since udf_next_aext() can returnerror now. On situations like ftruncate, udf_extend_file() can nowdetect errors and bail out early without resorting to checking forparticular offsets and assuming internal behavior of these functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: pass u64 to ocfs2_truncate_inline maybe overflowSyzbot reported a kernel BUG in ocfs2_truncate_inline. There are tworeasons for this: first, the parameter value passed is greater thanocfs2_max_inline_data_with_xattr, second, the start and end parameters ofocfs2_truncate_inline are "unsigned int".So, we need to add a sanity check for byte_start and byte_len right beforeocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greaterthan ocfs2_max_inline_data_with_xattr return -EINVAL.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: do not pass a stopped vif to the driver in .get_txpowerAvoid potentially crashing in the driver because of uninitialized private data
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reinitialize delayed ref list after deleting it from the listAt insert_delayed_ref() if we need to update the action of an existingref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head'sref_add_list using list_del(), which leaves the ref's add_list membernot reinitialized, as list_del() sets the next and prev members of thelist to LIST_POISON1 and LIST_POISON2, respectively.If later we end up calling drop_delayed_ref() against the ref, which canhappen during merging or when destroying delayed refs due to a transactionabort, we can trigger a crash since at drop_delayed_ref() we calllist_empty() against the ref's add_list, which returns false sincethe list was not reinitialized after the list_del() and as a consequencewe call list_del() again at drop_delayed_ref(). This results in aninvalid list access since the next and prev members are set to poisonpointers, resulting in a splat if CONFIG_LIST_HARDENED andCONFIG_DEBUG_LIST are set or invalid poison pointer dereferencesotherwise.So fix this by deleting from the list with list_del_init() instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix flushing uninitialized delayed_work on cache_ctr errorAn unexpected WARN_ON from flush_work() may occur when cache creationfails, caused by destroying the uninitialized delayed_work waker in theerror path of cache_create(). For example, the warning appears on thesuperblock checksum error.Reproduce steps:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890Fix by pulling out the cancel_delayed_work_sync() from the constructor'serror path. This patch doesn't affect the use-after-free fix forconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: FixUAF in destroy()")) as cache_dtr is not changed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: prevent the risk of a division by zeroAs reported by Coverity, the logic at tpg_precalculate_line()blindly rescales the buffer even when scaled_witdh is equal tozero. If this ever happens, this will cause a division by zero.Instead, add a WARN_ON_ONCE() to trigger such cases and returnwithout doing any precalculation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: av7110: fix a spectre vulnerabilityAs warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)There is a spectre-related vulnerability at the code. Fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when uninstalling driverWhen the driver is uninstalled and the VF is disabled concurrently, akernel crash occurs. The reason is that the two actions call functionpci_disable_sriov(). The num_VFs is checked to determine whether torelease the corresponding resources. During the second calling, num_VFsis not 0 and the resource release function is called. However, thecorresponding resource has been released during the first invoking.Therefore, the problem occurs:[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020...[15278.131557][T50670] Call trace:[15278.134686][T50670] klist_put+0x28/0x12c[15278.138682][T50670] klist_del+0x14/0x20[15278.142592][T50670] device_del+0xbc/0x3c0[15278.146676][T50670] pci_remove_bus_device+0x84/0x120[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c[15278.162485][T50670] sriov_disable+0x50/0x11c[15278.166829][T50670] pci_disable_sriov+0x24/0x30[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3][15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge][15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30[15278.193848][T50670] invoke_syscall+0x50/0x11c[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164[15278.203837][T50670] do_el0_svc+0x34/0xcc[15278.207834][T50670] el0_svc+0x20/0x30For details, see the following figure. rmmod hclge disable VFs----------------------------------------------------hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock();In this patch, when driver is removing, we get the device_lock()to protect num_VFs, just like sriov_numvfs_store().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32values that come from the user via the submit_lookup_cmds() function.This addition could lead to an integer wrapping bug so use size_add()to prevent that.Patchwork: https://patchwork.freedesktop.org/patch/624696/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB dataIn case the non-paged data of a SKB carries protocol header and protocolpayload to be transmitted on a certain platform that the DMA AXI addresswidth is configured to 40-bit/48-bit, or the size of the non-paged datais bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXIaddress width is configured to 32-bit, then this SKB requires at leasttwo DMA transmit descriptors to serve it.For example, three descriptors are allocated to split one DMA buffermapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2].Then three elements of tx_q->tx_skbuff_dma[] will be allocated to holdextra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2].Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA bufferaddress returned by DMA mapping call. stmmac_tx_clean() will try tounmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].bufis a valid buffer address.The expected behavior that saves DMA buffer address of this non-pageddata to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL;On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by theDMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer addressobviously, then the DMA buffer will be unmapped immediately.There may be a rare case that the DMA engine does not finish thepending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will gohorribly wrong, DMA is going to access a unmapped/unreferenced memoryregion, corrupted data will be transmited or iommu fault will betriggered :(In contrast, the for-loop that maps SKB fragments behaves perfectlyas expected, and that is how the driver should do for both non-pageddata and paged frags actually.This patch corrects DMA map/unmap sequences by fixing the array indexfor tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.Tested and verified on DWXGMAC CORE 3.20a
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Fix KMSAN warning in decode_getfattr_attrs()Fix the following KMSAN warning:CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G BTainted: [B]=BAD_PAGEHardware name: QEMU Standard PC (Q35 + ICH9, 2009)==========================================================================================================BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe KMSAN warning is triggered in decode_getfattr_attrs(), when callingdecode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is notinitialized.Fix the issue by initializing fattr->mdsthreshold to NULL innfs_fattr_init().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Lock TPM chip in tpm_pm_suspend() firstSetting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racyaccording, as this leaves window for tpm_hwrng_read() to be called whilethe operation is in progress. The recent bug report gives also evidence ofthis behaviour.Aadress this by locking the TPM chip before checking any chip->flags bothin tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDEDcheck inside tpm_get_random() so that it will be always checked only whenthe lock is reserved.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 clientA number of Zen4 client SoCs advertise the ability to use virtualizedVMLOAD/VMSAVE, but using these instructions is reported to be a causeof a random host reboot.These instructions aren't intended to be advertised on Zen4 clientso clear the capability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: revert "mm: shmem: fix data-race in shmem_getattr()"Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") assuggested by Chuck [1]. It is causing deadlocks when accessing tmpfs overNFS.As Hugh commented, "added just to silence a syzbot sanitizer splat: addedwhere there has never been any practical problem".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LEThis aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4("Bluetooth: Always request for user confirmation for Just Works")always request user confirmation with confirm_hint set since thelikes of bluetoothd have dedicated policy around JUST_WORKS method(e.g. main.conf:JustWorksRepairing).CVE: CVE-2024-8805
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: fastmap: Fix duplicate slab cache names while attachingSince commit 4c39529663b9 ("slab: Warn on duplicate cache names whenDEBUG_VM=y"), the duplicate slab cache names can be detected and akernel WARNING is thrown out.In UBI fast attaching process, alloc_ai() could be invoked twicewith the same slab cache name 'ubi_aeb_slab_cache', which will triggerfollowing warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0The problem could be easily reproduced by loading UBI device by fastmapwith CONFIG_DEBUG_VM=y.Fix it by using different slab names for alloc_ai() callers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent NULL dereference in nfsd4_process_cb_update()@ses is initialized to NULL. If __nfsd4_find_backchannel() finds noavailable backchannel session, setup_callback_client() will try todereference @ses and segfault.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen/netfront: fix crash when removing deviceWhen removing a netfront device directly after a suspend/resume cycleit might happen that the queues have not been setup again, causing acrash during the attempt to stop the queues another time.Fix that by checking the queues are existing before trying to stopthem.This is XSA-465 / CVE-2024-53240.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Filter invalid inodes with missing lookup functionAdd a check to the ovl_dentry_weird() function to prevent theprocessing of directory inodes that lack the lookup function.This is important because such inodes can cause errors in overlayfswhen passed to the lowerstack.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix NULL deref in cleanup_bearer()syzbot found [1] that after blamed commit, ub->ubsock->skwas NULL when attempting the atomic_dec() :atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count);Fix this by caching the tipc_net pointer.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events cleanup_bearer RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1bRSP: 0018:ffffc9000410fb70 EFLAGS: 00010206RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/xen: fix release of IRQKernel logs indicate an IRQ was double-freed.Pass correct device ID during IRQ release.[Dominique: remove confusing variable reset to 0]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix cpu stuck caused by printings during resetDuring reset, cmd to destroy resources such as qp, cq, and mr may fail,and error logs will be printed. When a large number of resources aredestroyed, there will be lots of printings, and it may lead to a cpustuck.Delete some unnecessary printings and replace other printing functionsin these paths with the ratelimited version.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rtc: check if __rtc_read_time was successful in rtc_timer_do_work()If the __rtc_read_time call fails,, the struct rtc_time tm; may containuninitialized data, or an illegal date/time read from the RTC hardware.When calling rtc_tm_to_ktime later, the result may be a very large value(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,they will continually expire, may causing kernel softlockup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM workerAfter commit746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720... [ ] The intent of the verifcation done in check_flush_depedency is to ensureforward progress during memory reclaim, by flagging cases when either amemory reclaim process, or a memory reclaim work item is flushed from acontext not marked as memory reclaim safe.This is correct when flushing, but when called from thecancel(_delayed)_work_sync() paths it is a false positive because work iseither already running, or will not be running at all. Thereforecancelling it is safe and we can relax the warning criteria by letting thehelper know of the calling context.References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed. Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: flush delalloc workers queue before stopping cleaner kthread during unmountDuring the unmount path, at close_ctree(), we first stop the cleanerkthread, using kthread_stop() which frees the associated task_struct, andthen stop and destroy all the work queues. However after we stopped thecleaner we may still have a worker from the delalloc_workers queue runninginode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),which in turn tries to wake up the cleaner kthread - which was alreadydestroyed before, resulting in a use-after-free on the task_struct.Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rdma/cxgb4: Prevent potential integer overflow on 32bitThe "gl->tot_len" variable is controlled by the user. It comes fromprocess_responses(). On 32bit systems, the "gl->tot_len + sizeof(structcpl_pass_accept_req) + sizeof(struct rss_header)" addition could have aninteger wrapping bug. Use size_add() to prevent this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pps: Fix a use-after-freeOn a board running ntpd and gpsd, I'm seeing a consistent use-after-freein sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]---...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exceptionThis happens because pps_device_destruct() frees the pps_device with theembedded cdev immediately after calling cdev_del(), but, as the commentabove cdev_del() notes, fops for previously opened cdevs are stillcallable even after cdev_del() returns. I think this bug has alwaysbeen there: I can't explain why it suddenly started happening every timeI reboot this particular board.In commit d953e0e837e6 ("pps: Fix a use-after free bug whenunregistering a source."), George Spelvin suggested removing theembedded cdev. That seems like the simplest way to fix this, so I'veimplemented his suggestion, using __register_chrdev() with pps_idrbecoming the source of truth for which minor corresponds to whichdevice.But now that pps_idr defines userspace visibility instead of cdev_add(),we need to be sure the pps->dev refcount can't reach zero whileuserspace can still find it again. So, the idr_remove() call moves topps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix double free in error pathIf the uvc_status_init() function fails to allocate the int_urb, it willfree the dev->status pointer but doesn't reset the pointer to NULL. Thisresults in the kfree() call in uvc_status_cleanup() trying todouble-free the memory. Fix it by resetting the dev->status pointer toNULL after freeing it.Reviewed by: Ricardo Ribalda
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix NULL pointer dereference on certain command abortsIf a command is queued to the final usable TRB of a ring segment, theenqueue pointer is advanced to the subsequent link TRB and no further.If the command is later aborted, when the abort completion is handledthe dequeue pointer is advanced to the first TRB of the next segment.If no further commands are queued, xhci_handle_stopped_cmd_ring() seesthe ring pointers unequal and assumes that there is a pending command,so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbellring likely is unnecessary too, but it's harmless. Leave it alone.This is probably Bug 219532, but no confirmation has been received.The issue has been independently reproduced and confirmed fixed usinga USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.Everything continued working normally after several prevented crashes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: fix out-of-bounds read during lookuplookup and resize can run in parallel.The xfrm_state_hash_generation seqlock ensures a retry, but the hashfunctions can observe a hmask value that is too large for the new hlistarray.rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {This is only safe in case the update to state_bydst is larger thannet->xfrm.xfrm_state_hmask (or if the lookup function getsserialized via state spinlock again).Fix this by prefetching state_hmask and the associated pointers.The xfrm_state_hash_generation seqlock retry will ensure that the pointerand the hmask will be consistent.The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,add lockdep assertions to document that they are only safe for insertside.xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.AFAICS this is an oversight from back when state lookup was converted toRCU, this lock should be replaced with RCU in a future patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: fix memory leaks and invalid access at probe error pathDeinitialize at reverse order when probe fails.When init_sw_vars fails, rtl_deinit_core should not be called, speciallynow that it destroys the rtl_wq workqueue.And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will beleaked.Remove pci_set_drvdata call as it will already be cleaned up by the coredriver code and could lead to memory leaks too. cf. commit 8d450935ae7f("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") andcommit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: prevent adding a device which is already a team device lowerPrevent adding a device which is already a team device lower,e.g. adding veth0 if vlan1 was already added and veth0 is a lower ofvlan1.This is not useful in practice and can lead to recursive locking:$ ip link add veth0 type veth peer name veth1$ ip link set veth0 up$ ip link set veth1 up$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1$ ip link add team0 type team$ ip link set veth0.1 down$ ip link set veth0.1 master team0team0: Port device veth0.1 added$ ip link set veth0 down$ ip link set veth0 master team0============================================WARNING: possible recursive locking detected6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted--------------------------------------------ip/7684 is trying to acquire lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)but task is already holding lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)other info that might help us debug this:Possible unsafe locking scenario:CPU0----lock(team->team_lock_key);lock(team->team_lock_key);*** DEADLOCK ***May be due to missing lock nesting notation2 locks held by ip/7684:stack backtrace:CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:122)print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? lock_acquire (kernel/locking/lockdep.c:5822)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? fib_sync_up (net/ipv4/fib_semantics.c:2167)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)__dev_notify_flags (net/core/dev.c:8993)? __dev_change_flags (net/core/dev.c:8975)dev_change_flags (net/core/dev.c:9027)vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)? br_device_event (net/bridge/br.c:143)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)dev_open (net/core/dev.c:1519 net/core/dev.c:1505)team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)do_set_master (net/core/rtnetlink.c:2917)do_setlink.isra.0 (net/core/rtnetlink.c:3117)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: remove unused check_buddy_privCommit 2461c7d60f9f ("rtlwifi: Update header file") introduced a globallist of private data structures.Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to matchvendor version 2013.02.07") started adding the private data to that list atprobe time and added a hook, check_buddy_priv to find the private data froma similar device.However, that function was never used.Besides, though there is a lock for that list, it is never used. And whenthe probe fails, the private data is never removed from the list. Thiswould cause a second probe to access freed memory.Remove the unused hook, structures and members, which will prevent thepotential race condition on the list and its corruption during a secondprobe when probe fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()Explicitly verify the target vCPU is fully online _prior_ to clamping theindex in kvm_get_vcpu(). If the index is "bad", the nospec clamping willgenerate '0', i.e. KVM will return vCPU0 instead of NULL.In practice, the bug is unlikely to cause problems, as it will only comeinto play if userspace or the guest is buggy or misbehaving, e.g. KVM maysend interrupts to vCPU0 instead of dropping them on the floor.However, returning vCPU0 when it shouldn't exist per online_vcpus isproblematic now that KVM uses an xarray for the vCPUs array, as KVM needsto insert into the xarray before publishing the vCPU to userspace (seecommit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),i.e. before vCPU creation is guaranteed to succeed.As a result, incorrectly providing access to vCPU0 will trigger ause-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()bails out of vCPU creation due to an error and frees vCPU0. Commitafb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, butin doing so introduced an unsolvable teardown conundrum. Preventingaccesses to vCPU0 before it's fully online will allow reverting commitafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free"), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free'd memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxslt1 > 0-0 (version in image is 1.1.28-17.15.1).
-
Description: Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc > 0-0 (version in image is 2.22-114.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: clamp maximum hashtable size to INT_MAXUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, itis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() whenresizing hashtable because __GFP_NOWARN is unset. See: 0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")Note: hashtable resize is only possible from init_netns.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: storvsc: Ratelimit warning logs to prevent VM denial of serviceIf there's a persistent error in the hypervisor, the SCSI warning forfailed I/O can flood the kernel log and max out CPU utilization,preventing troubleshooting from the VM side. Ratelimit the warning soit doesn't DoS the VM.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: don't allow reconnect after disconnectFollowing process can cause nbd_config UAF:1) grab nbd_config temporarily;2) nbd_genl_disconnect() flush all recv_work() and release theinitial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work)4) step 1) release the reference;5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAFFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), sothat nbd_genl_reconfigure() will fail.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the return value of of_property_read_string_index()Somewhen between 6.10 and 6.11 the driver started to crash on myMacBookPro14,3. The property doesn't exist and 'tmp' remainsuninitialized, so we pass a random pointer to devm_kstrdup().The crash I am getting looks like this:BUG: unable to handle page fault for address: 00007f033c669379PF: supervisor read access in kernel modePF: error_code(0x0001) - permissions violationPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025Oops: Oops: 0001 [#1] SMP PTICPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024RIP: 0010:strlen+0x4/0x30Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 ccRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916aR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: extend RCU protection in ndisc_send_skb()ndisc_send_skb() can be called without RTNL or RCU held.Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()and avoid a potential UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: use RCU protection in ndisc_alloc_skb()ndisc_alloc_skb() can be called without RTNL or RCU being held.Add RCU protection to avoid possible UAF.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU protection in ip6_default_advmss()ip6_default_advmss() needs rcu protection to makesure the net structure it reads does not disappear.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: use RCU protection in __ip_rt_update_pmtu()__ip_rt_update_pmtu() must use RCU protection to makesure the net structure it reads does not disappear.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix oops when unload drivers parallelingWhen unload hclge driver, it tries to disable sriov first for eachae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver atthe time, because it removes all the ae_dev nodes, and it may causeoops.But we can't simply use hnae3_common_lock for this. Because in theprocess flow of pci_disable_sriov(), it will trigger the remove flowof VF, which will also take hnae3_common_lock.To fixes it, introduce a new mutex to protect the unload process.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi's weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi's weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acct: perform last write from workqueueIn [1] it was reported that the acct(2) system call can be used totrigger NULL deref in cases where it is set to write to a file thattriggers an internal lookup. This can e.g., happen when pointing acc(2)to /sys/power/resume. At the point the where the write to this filehappens the calling task has already exited and called exit_fs(). Alookup will thus trigger a NULL-deref when accessing current->fs.Reorganize the code so that the the final write happens from theworkqueue but with the caller's credentials. This preserves the(strange) permission model and has almost no regression risk.This api should stop to exist though.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()Add check for the return value of nfp_app_ctrl_msg_alloc() innfp_bpf_cmsg_alloc() to prevent null pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)->geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let's call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: fix incorrect initialization orderSyzkaller reports the following bug:BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7RIP: 0033:0x7f3f9815aee9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768If drop_monitor is built as a kernel module, syzkaller may have timeto send a netlink NET_DM_CMD_START message during the module loading.This will call the net_dm_monitor_start() function that usesa spinlock that has not yet been initialized.To fix this, let's place resource initialization above the registrationof a generic netlink family.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().Brad Spengler reported the list_del() corruption splat ingtp_net_exit_batch_rtnl(). [0]Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netnsdismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()to destroy devices in each netns as done in geneve and ip tunnels.However, this could trigger ->dellink() twice for the same device during->exit_batch_rtnl().Say we have two netns A & B and gtp device B that resides in netns B butwhose UDP socket is in netns A. 1. cleanup_net() processes netns A and then B. 2. gtp_net_exit_batch_rtnl() finds the device B while iterating netns A's gn->gtp_dev_list and calls ->dellink(). [ device B is not yet unlinked from netns B as unregister_netdevice_many() has not been called. ] 3. gtp_net_exit_batch_rtnl() finds the device B while iterating netns B's for_each_netdev() and calls ->dellink().gtp_dellink() cleans up the device's hash table, unlinks the dev fromgn->gtp_dev_list, and calls unregister_netdevice_queue().Basically, calling gtp_dellink() multiple times is fine unlessCONFIG_DEBUG_LIST is enabled.Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() anddelegate the destruction to default_device_exit_batch() as donein bareudp.[0]:list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)kernel BUG at lib/list_debug.c:58!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1Tainted: [T]=RANDSTRUCTHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: netns cleanup_netRIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08RBX: kasan shadow of 0x0RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360dCall Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix supplicant wait loopOP-TEE supplicant is a user-space daemon and it's possible for itbe hung or crashed or killed in the middle of processing an OP-TEERPC call. It becomes more complicated when there is incorrect shutdownordering of the supplicant process vs the OP-TEE client application whichcan eventually lead to system hang-up waiting for the closure of theclient application.Allow the client process waiting in kernel for supplicant response tobe killed rather than indefinitely waiting in an unkillable state. Also,a normal uninterruptible wait should not have resulted in the hung-taskwatchdog getting triggered, but the endless loop would.This fixes issues observed during system reboot/shutdown when supplicantgot hung for some reason or gets crashed/killed which lead to clientgetting hung in an unkillable state. It in turn lead to system being inhung up state requiring hard power off/on to recover.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: Reject the shared zeropage in uprobe_write_opcode()We triggered the following crash in syzkaller tests: BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1The following syzkaller test case can be used to reproduce: r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)The cause is that zero pfn is set to the PTE without increasing the RSScount in mfill_atomic_pte_zeropage() and the refcount of zero folio doesnot increase accordingly. Then, the operation on the same pfn is performedin uprobe_write_opcode()->__replace_page() to unconditional decrease theRSS count and old_folio's refcount.Therefore, two bugs are introduced: 1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count". 2. The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".There is more, the following warning could also theoretically be triggered: __replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)Considering that uprobe hit on the zero folio is a very rare case, justreject zero old folio immediately after get_user_page_vma_remote().[ mingo: Cleaned up the changelog ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: ensure network headers are in skb linear partsyzbot found that ipvlan_process_v6_outbound() was assumingthe IPv6 network header isis present in skb->head [1]Add the needed pskb_network_may_pull() calls for bothIPv4 and IPv6 handlers.[1]BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don't care about rec->counter * rec->counter overflow becauserec->time * rec->time overflow will likely happen earlier.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject cooked mode if it is set along with other flagsIt is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVEflags simultaneously on the same monitor interface from the userspace. Thiscauses a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bitset because the monitor interface is in the cooked state and it takesprecedence over all other states. When the interface is then being deletedthe kernel calls WARN_ONCE() from check_sdata_in_driver() because of missingthat bit.Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along withother flags.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: regulatory: improve invalid hints checkingSyzbot keeps reporting an issue [1] that occurs when erroneous symbolssent from userspace get through into user_alpha2[] viaregulatory_hint_user() call. Such invalid regulatory hints should berejected.While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:reject invalid hints") looks to be enough to deter these very cases,there is a way to get around it due to 2 reasons.1) The way isalpha() works, symbols other than latin lower andupper letters may be used to determine a country/domain.For instance, greek letters will also be considered upper/lowerletters and for such characters isalpha() will return true as well.However, ISO-3166-1 alpha2 codes should only hold latincharacters.2) While processing a user regulatory request, betweenreg_process_hint_user() and regulatory_hint_user() there happens tobe a call to queue_regulatory_request() which modifies letters inrequest->alpha2[] with toupper(). This works fine for latin symbols,less so for weird letter characters from the second part of _ctype[].Syzbot triggers a warning in is_user_regdom_saved() by first sendingover an unexpected non-latin letter that gets malformed by toupper()into a character that ends up failing isalpha() check.Prevent this by enhancing is_an_alpha2() to ensure that incomingsymbols are latin letters and nothing else.[1] Syzbot report:------------[ cut here ]------------Unexpected user alpha2: A�WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516Modules linked in:CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events_power_efficient crda_timeout_workRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516...Call Trace: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix a flaw in existing endpoint checksSyzbot once again identified a flaw in usb endpoint checking, see [1].This time the issue stems from a commit authored by me (2eabb655a968("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).While using usb_find_common_endpoints() may usually be enough todiscard devices with wrong endpoints, in this case one needs morethan just finding and identifying the sufficient number of endpointsof correct types - one needs to check the endpoint's address as well.Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,switch the endpoint verification approach to usb_check_XXX_endpoints()instead to fix incomplete ep testing.[1] Syzbot report:usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...Call Trace: cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vlan: enforce underlying device typeCurrently, VLAN devices can be created on top of non-ethernet devices.Besides the fact that it doesn't make much sense, this also causes abug which leaks the address of a kernel function to usermode.When creating a VLAN device, we initialize GARP (garp_init_applicant)and MRP (mrp_init_applicant) for the underlying device.As part of the initialization process, we add the multicast address ofeach applicant to the underlying device, by calling dev_mc_add.__dev_mc_add uses dev->addr_len to determine the length of the newmulticast address.This causes an out-of-bounds read if dev->addr_len is greater than 6,since the multicast addresses provided by GARP and MRP are only 6bytes long.This behaviour can be reproduced using the following commands:ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev loip l set up dev gretestip link add link gretest name vlantest type vlan id 100Then, the following command will display the address of garp_pdu_rcv:ip maddr show | grep 01:80:c2:00:00:21Fix the bug by enforcing the type of the underlying device during VLANdevice initialization.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix ownership in __udp_gso_segmentIn __udp_gso_segment the skb destructor is removed before segmenting theskb but the socket reference is kept as-is. This is an issue if theoriginal skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50The above can happen following a sequence of events when usingOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes anOVS_ACTION_ATTR_OUTPUT action:1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed.2. The segments' data are copied and sent to userspace.3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path.4. If it later hits skb_orphan, we hit the bug.Fix this by also removing the reference to the socket in__udp_gso_segment.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()nvme_tcp_recv_pdu() doesn't check the validity of the header length.When header digests are enabled, a target might send a packet with aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folioCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages tobe offlined) add page poison checks in do_migrate_range in order to makeoffline hwpoisoned page possible by introducing isolate_lru_page andtry_to_unmap for hwpoisoned page. However folio lock must be held beforecalling try_to_unmap. Add it to fix this problem.Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: fix an API misues when rio_add_net() failsrio_add_net() calls device_register() and fails when device_register()fails. Thus, put_device() should be used rather than kfree(). Add"mport->net = NULL;" to avoid a use after free issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked. If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_paramsNull pointer dereference issue could occur when pipe_ctx->plane_stateis null. The fix adds a check to ensure 'pipe_ctx->plane_state' is notnull before accessing. This prevents a null pointer dereference.Found by code review.(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: appleir: Fix potential NULL dereference at raw event handleSyzkaller reports a NULL pointer dereference issue in input_event().BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395Read of size 8 at addr 0000000000000028 by task syz-executor199/2949CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens due to the malformed report items sent by the emulated devicewhich results in a report, that has no fields, being added to the report list.Due to this appleir_input_configured() is never called, hidinput_connect()fails which results in the HID_CLAIMED_INPUT flag is not being set. However,it does not make appleir_probe() fail and lets the event callback to becalled without the associated input device.Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hookearly if the driver didn't claim any input_dev for some reason. Moreover,some other hid drivers accessing input_dev in their event callbacks do havesimilar checks, too.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acdirmax mount optionUser-provided mount parameter acdirmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acregmax mount optionUser-provided mount parameter acregmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmdAfter the hci sync command releases l2cap_conn, the hci receive data workqueue references the released l2cap_conn when sending to the upper layer.Add hci dev lock to the hci receive data work queue to synchronize the two.[1]BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: hci1 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()On the off chance that command stream passed from userspace viaioctl() call to radeon_vce_cs_parse() is weirdly crafted andfirst command to execute is to encode (case 0x03000001), the functionin question will attempt to call radeon_vce_cs_reloc() with sizeargument that has not been properly initialized. Specifically, 'size'will point to 'tmp' variable before the latter had a chance to beassigned any value.Play it safe and init 'tmp' with 0, thus ensuring thatradeon_vce_cs_reloc() will catch an early error in cases like these.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix error code in chan_alloc_skb_cb()The chan_alloc_skb_cb() function is supposed to return error pointers onerror. Returning NULL will lead to a NULL dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: check that dummy regulator has been probed before using itDue to asynchronous driver probing there is a chance that the dummyregulator hasn't already been probed when first accessing it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup during bt pages loopDriver runs a for-loop when allocating bt pages and mapping them withbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bcAdd a cond_resched() to fix soft lockup during these loops. In order notto affect the allocation performance of normal-size buffer, set the loopcount of a 100GB MR as the threshold to call cond_resched().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Fix NULL pointer dereferenceWhen MPOA_cache_impos_rcvd() receives the msg, it can triggerNull Pointer Dereference Vulnerability if both entry andholding_time are NULL. Because there is only for the situationwhere entry is NULL and holding_time exists, it can be passedwhen both entry and holding_time are NULL. If these are NULL,the entry will be passd to eg_cache_put() as parameter andit is referenced by entry->use code in it.kasan log:[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0[ 3.326430] Call Trace:[ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0[ 3.327330] ? exc_general_protection+0x161/0x2a0[ 3.327662] ? asm_exc_general_protection+0x26/0x30[ 3.328214] ? vprintk_emit+0x15e/0x420[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10[ 3.329664] ? console_unlock+0x107/0x1d0[ 3.329946] ? __pfx_console_unlock+0x10/0x10[ 3.330283] ? do_syscall_64+0xa6/0x1a0[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10[ 3.331395] ? down_trylock+0x52/0x80[ 3.331703] ? vprintk_emit+0x15e/0x420[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10[ 3.332279] ? down_trylock+0x52/0x80[ 3.332527] ? _printk+0xbf/0x100[ 3.332762] ? __pfx__printk+0x10/0x10[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10[ 3.333614] msg_from_mpoad+0x1185/0x2750[ 3.333893] ? __build_skb_around+0x27b/0x3a0[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10[ 3.334501] ? __alloc_skb+0x1c0/0x310[ 3.334809] ? __pfx___alloc_skb+0x10/0x10[ 3.335283] ? _raw_spin_lock+0xe0/0xe0[ 3.335632] ? finish_wait+0x8d/0x1e0[ 3.335975] vcc_sendmsg+0x684/0xba0[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10[ 3.337056] ? fdget+0x176/0x3e0[ 3.337348] __sys_sendto+0x4a2/0x510[ 3.337663] ? __pfx___sys_sendto+0x10/0x10[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400[ 3.338364] ? sock_ioctl+0x1bb/0x5a0[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10[ 3.339727] ? selinux_file_ioctl+0xa4/0x260[ 3.340166] __x64_sys_sendto+0xe0/0x1c0[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140[ 3.340898] do_syscall_64+0xa6/0x1a0[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 3.341533] RIP: 0033:0x44a380[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00[ ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet:fix NPE during rx_completeMissing usbnet_going_away Check in Critical Path.The usb_submit_urb function lacks a usbnet_going_awayvalidation, whereas __usbnet_queue_skb includes this check.This inconsistency creates a race condition where:A URB request may succeed, but the corresponding SKB datafails to be queued.Subsequent processes:(e.g., rx_complete -> defer_bh -> __skb_unlink(skb, list))attempt to access skb->next, triggering a NULL pointerdereference (Kernel Panic).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ibmveth: make veth_pool_store stop hangingv2:- Created a single error handling unlock and exit in veth_pool_store- Greatly expanded commit message with previous explanatory-only textSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,ibmveth_close and ibmveth_open, preventing multiple calls in a row tonapi_disable.Background: Two (or more) threads could call veth_pool_store throughwriting to /sys/devices/vio/30000002/pool*/*. You can do this easilywith a little shell script. This causes a hang.I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a newkernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: Prevent parser TCAM memory corruptionProtect the parser TCAM/SRAM memory, and the cached (shadow) SRAMinformation, from concurrent modifications.Both the TCAM and SRAM tables are indirectly accessed by configuringan index register that selects the row to read or write to. This meansthat operations must be atomic in order to, e.g., avoid spreadingwrites across multiple rows. Since the shadow SRAM array is used tofind free rows in the hardware table, it must also be protected inorder to avoid TOCTOU errors where multiple cores allocate the samerow.This issue was detected in a situation where `mvpp2_set_rx_mode()` ranconcurrently on two CPUs. In this particular case theMVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing theclassifier unit to drop all incoming unicast - indicated by the`rx_classifier_drops` counter.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flowWhen cur_qp isn't NULL, in order to avoid fetching the QP fromthe radix tree again we check if the next cqe QP is identical tothe one we already have.The bug however is that we are checking if the QP is identical bychecking the QP number inside the CQE against the QP number inside themlx5_ib_qp, but that's wrong since the QP number from the CQE is fromFW so it should be matched against mlx5_core_qp which is our FW QPnumber.Otherwise we could use the wrong QP when handling a CQE which couldcause the kernel trace below.This issue is mainly noticeable over QPs 0 & 1, since for now they arethe only QPs in our driver whereas the QP number inside mlx5_ib_qpdoesn't match the QP number inside mlx5_core_qp.BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: int340x: Add NULL check for adevNot all devices have an ACPI companion fwnode, so adev might be NULL.This is similar to the commit cd2fd6eab480("platform/x86: int3472: Check for adev == NULL").Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in int3402_thermal_probe().Note, under the same directory, int3400_thermal_probe() has such acheck.[ rjw: Subject edit, added Fixes: ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accessesAcquire a lock on kvm->srcu when userspace is getting MP state to handle arather extreme edge case where "accepting" APIC events, i.e. processingpending INIT or SIPI, can trigger accesses to guest memory. If the vCPUis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MPstate will trigger a nested VM-Exit by way of ->check_nested_events(), andemuating the nested VM-Exit can access guest memory.The splat was originally hit by syzkaller on a Google-internal kernel, andreproduced on an upstream kernel by hacking the triple_fault_event_testselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate amemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: do not start chip while suspendedChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() canlead to a spurious tpm_chip_start() call:[35985.503771] i2c i2c-1: Transfer while suspended[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810[35985.503802] Modules linked in:[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f[35985.503814] Tainted: [W]=WARN[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0[35985.503855] Call Trace:[35985.503859] [35985.503863] ? __warn+0xd4/0x260[35985.503868] ? __i2c_transfer+0xbe/0x810[35985.503874] ? report_bug+0xf3/0x210[35985.503882] ? handle_bug+0x63/0xb0[35985.503887] ? exc_invalid_op+0x16/0x50[35985.503892] ? asm_exc_invalid_op+0x16/0x20[35985.503904] ? __i2c_transfer+0xbe/0x810[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0[35985.503920] tpm_cr50_i2c_read+0x8e/0x120[35985.503928] tpm_cr50_request_locality+0x75/0x170[35985.503935] tpm_chip_start+0x116/0x160[35985.503942] tpm_try_get_ops+0x57/0x90[35985.503948] tpm_find_get_ops+0x26/0xd0[35985.503955] tpm_get_random+0x2d/0x80Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unlessTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL insuch a failure case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix off-by-one error in do_splitSyzkaller detected a use-after-free issue in ext4_insert_dentry that wascaused by out-of-bounds access due to incorrect splitting in do_split.BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement.for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++;}'i' in this case could go down to -1, in which case sum of active entrieswouldn't exceed half the block size, but previous behaviour would also dosplit in half if sum would exceed at the very last block, which in case ofhaving too many long name files in a single block could lead toout-of-bounds access and following use-after-free.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t typeThe access to the PCI config space via pci_ops::read and pci_ops::write isa low-level hardware access. The functions can be accessed with disabledinterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for thispurpose.A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot beacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed inthe same context as the pci_lock.Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used withinterrupts disabled.This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90[bigeasy: reword commit message]Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log][bhelgaas: add back report info fromhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: don't propagate flags on openWith the device instance lock, there is now a possibility of a deadlock:[ 1.211455] ============================================[ 1.211571] WARNING: possible recursive locking detected[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted[ 1.211823] --------------------------------------------[ 1.211936] ip/184 is trying to acquire lock:[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0[ 1.212207][ 1.212207] but task is already holding lock:[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.212487][ 1.212487] other info that might help us debug this:[ 1.212626] Possible unsafe locking scenario:[ 1.212626][ 1.212751] CPU0[ 1.212815] ----[ 1.212871] lock(&dev->lock);[ 1.212944] lock(&dev->lock);[ 1.213016][ 1.213016] *** DEADLOCK ***[ 1.213016][ 1.213143] May be due to missing lock nesting notation[ 1.213143][ 1.213294] 3 locks held by ip/184:[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.213895][ 1.213895] stack backtrace:[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014[ 1.213994] Call Trace:[ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0[ 1.214000] print_deadlock_bug+0x28b/0x2a0[ 1.214020] lock_acquire+0xea/0x2a0[ 1.214027] __mutex_lock+0xbf/0xd40[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev[ 1.214042] __dev_open+0x145/0x270[ 1.214046] __dev_change_flags+0xb0/0x1e0[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0[ 1.214058] notifier_call_chain+0x78/0x120[ 1.214062] netif_open+0x6d/0x90[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0[ 1.214066] bond_enslave+0x64c/0x1230[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0[ 1.214077] do_setlink+0x516/0x13b0[ 1.214094] rtnl_newlink+0xaba/0xb80[ 1.214132] rtnetlink_rcv_msg+0x440/0x490[ 1.214144] netlink_rcv_skb+0xeb/0x120[ 1.214150] netlink_unicast+0x1f9/0x320[ 1.214153] netlink_sendmsg+0x346/0x3f0[ 1.214157] __sock_sendmsg+0x86/0xb0[ 1.214160] ____sys_sendmsg+0x1c8/0x220[ 1.214164] ___sys_sendmsg+0x28f/0x2d0[ 1.214179] __x64_sys_sendmsg+0xef/0x140[ 1.214184] do_syscall_64+0xec/0x1d0[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 1.214191] RIP: 0033:0x7f2d1b4a7e56Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down)When we enslave the lower device (netdevsim0) which has a vlan, wepropagate vlan's allmuti/promisc flags during ndo_open. This causes(re)locking on of the real_dev.Propagate allmulti/promisc on flags change, not on the open. Thereis a slight semantics change that vlans that are down now propagatethe flags, but this seems unlikely to result in the real issues.Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libX11-6 < 1.6.2-12.36.1 (version in image is 1.6.2-12.33.1).
-
Description: In SQLite 3.49.0 before 3.49.1, certain argument values to sqlite3_db_config (in the C-language API) can cause a denial of service (application crash). An sz*nBig multiplication is not cast to a 64-bit integer, and consequently some memory allocations may be incorrect.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsqlite3-0 < 3.49.1-9.33.1 (version in image is 3.39.3-9.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: explicitly disallow disconnectsyzbot discovered that it can disconnect a TLS socket and thenrun into all sort of unexpected corner cases. I have a vaguerecollection of Eric pointing this out to us a long time ago.Supporting disconnect is really hard, for one thing if offloadis enabled we'd need to wait for all packets to be _acked_.Disconnect is not commonly used, disallow it.The immediate problem syzbot run into is the warning in the strp,but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix memory leak in tipc_link_xmitIn case the backlog transmit queue for system-importance messages is overloaded,tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads tomemory leak and failure when a skb is allocated.This commit fixes this issue by purging the skb list before tipc_link_xmit()returns.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Prevent the use of too small fidsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]The handle_bytes value passed in by the reproducing program is equal to 12.In handle_to_path(), only 12 bytes of memory are allocated for the structurefile_handle->f_handle member, which causes an out-of-bounds access whenaccessing the member parent_block of the structure isofs_fid in isofs,because accessing parent_block requires at least 16 bytes of f_handle.Here, fh_len is used to indirectly confirm that the value of handle_bytesis greater than 3 before accessing parent_block.[1]BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cros-ec-tunnel: defer probe if parent EC is not presentWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parentdevice will not be found, leading to NULL pointer dereference.That can also be reproduced by unbinding the controller driver and thenloading i2c-cros-ec-tunnel module (or binding the device).[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058[ 271.998215] #PF: supervisor read access in kernel mode[ 272.003351] #PF: error_code(0x0000) - not-present page[ 272.008485] PGD 0 P4D 0[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel][ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0[ 272.129155] Call Trace:[ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110[ 272.137985] platform_probe+0x69/0xa0[ 272.141652] really_probe+0x152/0x310[ 272.145318] __driver_probe_device+0x77/0x110[ 272.149678] driver_probe_device+0x1e/0x190[ 272.153864] __driver_attach+0x10b/0x1e0[ 272.157790] ? driver_attach+0x20/0x20[ 272.161542] bus_for_each_dev+0x107/0x150[ 272.165553] bus_add_driver+0x15d/0x270[ 272.169392] driver_register+0x65/0x110[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698][ 272.182617] do_one_initcall+0x110/0x350[ 272.186543] ? security_kernfs_init_security+0x49/0xd0[ 272.191682] ? __kernfs_new_node+0x1b9/0x240[ 272.195954] ? security_kernfs_init_security+0x49/0xd0[ 272.201093] ? __kernfs_new_node+0x1b9/0x240[ 272.205365] ? kernfs_link_sibling+0x105/0x130[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0[ 272.214773] ? kernfs_activate+0x57/0x70[ 272.218699] ? kernfs_add_one+0x118/0x160[ 272.222710] ? __kernfs_create_file+0x71/0xa0[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110[ 272.232033] ? internal_create_group+0x453/0x4a0[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0[ 272.241355] ? __free_frozen_pages+0x1dc/0x420[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0[ 272.250505] ? load_module+0x1509/0x16f0[ 272.254431] do_init_module+0x60/0x230[ 272.258181] __se_sys_finit_module+0x27a/0x370[ 272.262627] do_syscall_64+0x6a/0xf0[ 272.266206] ? do_syscall_64+0x76/0xf0[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 272.279887] RIP: 0033:0x7b9309168d39[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt's not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Purge vif txq in ieee80211_do_stop()After ieee80211_do_stop() SKB from vif's txq could still be processed.Indeed another concurrent vif schedule_and_wake_txq call could causethose packets to be dequeued (see ieee80211_handle_wake_tx_queue())without checking the sdata current state.Because vif.drv_priv is now cleared in this function, this could lead todriver crash.For example in ath12k, ahvif is store in vif.drv_priv. Thus ifath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can beNULL, leading the ath12k_warn(ahvif->ah,...) call in this function totrigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158To avoid that, empty vif's txq at ieee80211_do_stop() so no packet couldbe dequeued after ieee80211_do_stop() (new packets cannot be queuedbecause SDATA_STATE_RUNNING is cleared at this point).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: at76c50x: fix use after free access in at76_disconnectThe memory pointed to by priv is freed at the end of at76_delete_devicefunction (using ieee80211_free_hw). But the code then accesses the udevfield of the freed object to put the USB device. This may also lead to amemory leak of the usb device. Fix this by using udev from interface.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix potential NULL pointer dereference in dev_uevent()If userspace reads "uevent" device attribute at the same time as anotherthreads unbinds the device from its driver, change to dev->driver from avalid pointer to NULL may result in crash. Fix this by using READ_ONCE()when fetching the pointer, and take bus' drivers klist lock to make suredriver instance will not disappear while we access it.Use WRITE_ONCE() when setting the driver pointer to ensure there is notearing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() tooSimilarly to the previous patch, we need to safe guard hfsc_dequeue()too. But for this one, we don't have a reliable reproducer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reference leak in pci_register_host_bridge()If device_register() fails, call put_device() to give up the reference toavoid a memory leak, per the comment at device_register().Found by code review.[bhelgaas: squash Dan Carpenter's double free fix fromhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: avoid NULL pointer dereference in dbg callcifs_server_dbg() implies server to be non-NULL somove call under condition to avoid NULL pointer dereference.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has adivide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()returns zero.This is presumably just a theoretical problem: COMPILE_TEST overridesthe dependency on RALINK which would select COMMON_CLK. Regardless it'sa good idea to check for the error explicitly to avoid divide-by-zero.Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()Add error handling to propagate amdgpu_cgs_create_device() failuresto the caller. When amdgpu_cgs_create_device() fails, release hwmgrand return -ENOMEM to prevent null pointer dereference.[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: pidff: Fix null pointer dereference in pidff_find_fieldsThis function triggered a null pointer dereference if used to search fora report that isn't implemented on the device. This happened both foroptional and required reports alike.The same logic was applied to pidff_find_special_field and althoughpidff_init_fields should return an error earlier if one of the requiredreports is missing, future modifications could change this logic andresurface this possible null pointer dereference again.LKML bug report:https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: decrease sc_count directly if fail to queue dl_recallA deadlock warning occurred when invoking nfs4_put_stid following a faileddl_recall queue operation: T1 T2 nfs4_laundromat nfs4_get_client_reaplist nfs4_anylock_blockers__break_lease spin_lock // ctx->flc_lock spin_lock // clp->cl_lock nfs4_lockowner_has_blockers locks_owner_has_blockers spin_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp->cl_lockWhen a file is opened, an nfs4_delegation is allocated with sc_countinitialized to 1, and the file_lease holds a reference to the delegation.The file_lease is then associated with the file through kernel_setlease.The disassociation is performed in nfsd4_delegreturn via the followingcall chain:nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg -->nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_leaseThe corresponding sc_count reference will be released after thisdisassociation.Since nfsd_break_one_deleg executes while holding the flc_lock, thedisassociation process becomes blocked when attempting to acquire flc_lockin generic_delete_lease. This means:1) sc_count in nfsd_break_one_deleg will not be decremented to 0;2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt toacquire cl_lock;3) Consequently, no deadlock condition is created.Given that sc_count in nfsd_break_one_deleg remains non-zero, we cansafely perform refcount_dec on sc_count directly. This approacheffectively avoids triggering deadlock warnings.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix WARN_ON(!ctx) in __free_event() for partial initMove the get_ctx(child_ctx) call and the child_event->ctx assignment tooccur immediately after the child event is allocated. Ensure thatchild_event->ctx is non-NULL before any subsequent error path withininherit_event calls free_event(), satisfying the assumptions of thecleanup code.Details:There's no clear Fixes tag, because this bug is a side-effect ofmultiple interacting commits over time (up to 15 years old), nota single regression.The code initially incremented refcount then assigned contextimmediately after the child_event was created. Later, an earlyvalidity check for child_event was added before therefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check wasadded, assuming event->ctx is valid if the pmu_ctx is valid.The problem is that the WARN_ON_ONCE() could trigger after the initialcheck passed but before child_event->ctx was assigned, violating itsprecondition. The solution is to assign child_event->ctx right afterits initial validation. This ensures the context exists for anysubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().To resolve it, defer the refcount update and child_event->ctx assignmentdirectly after child_event->pmu_ctx is set but before checking if theparent event is orphaned. The cleanup routine depends onevent->pmu_ctx being non-NULL before it verifies event->ctx isnon-NULL. This also maintains the author's original intent of passingin child_ctx to find_get_pmu_context before its refcount/assignment.[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:9p/net: fix improper handling of bogus negative read/write repliesIn p9_client_write() and p9_client_read_once(), if the serverincorrectly replies with success but a negative write/read count then wewould consider written (negative) <= rsize (positive) because bothvariables were signed.Make variables unsigned to avoid this problem.The reproducer linked below now fails with the following error insteadof a null pointer deref:9pnet: bogus RWRITE count (4294967295 > 3)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reset IRTE to host control if *new* route isn't postableRestore an IRTE back to host control (remapped or posted MSI mode) if the*new* GSI route prevents posting the IRQ directly to a vCPU, regardless ofthe GSI routing type. Updating the IRTE if and only if the new GSI is anMSI results in KVM leaving an IRTE posting to a vCPU.The dangling IRTE can result in interrupts being incorrectly delivered tothe guest, and in the worst case scenario can result in use-after-free,e.g. if the VM is torn down, but the underlying host IRQ isn't freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch_htb: make htb_deactivate() idempotentAlan reported a NULL pointer dereference in htb_next_rb_node()after we made htb_qlen_notify() idempotent.It turns out in the following case it introduced some regression:htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate()For htb_next_rb_node(), after calling the 1st htb_deactivate(), theclprio[prio]->ptr could be already set to NULL, which meanshtb_next_rb_node() is vulnerable here.For htb_deactivate(), although we checked qlen before calling it, incase of qlen==0 after qdisc_tree_reduce_backlog(), we may call it againwhich triggers the warning inside.To fix the issues here, we need to:1) Make htb_deactivate() idempotent, that is, simply return if we already call it before.2) Make htb_next_rb_node() safe against ptr==NULL.Many thanks to Alan for testing and for the reproducer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix uninit-value for saddr in do_output_route4syzbot reports for uninit-value for the saddr argument [1].commit 4754957f04f5 ("ipvs: do not use random local source address fortunnels") already implies that the input value of saddrshould be ignored but the code is still reading it which can preventto connect the route. Fix it by changing the argument to ret_saddr.[1]BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)Hardware name: Google Google Compute Engi---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: fix memory leak in wl1251_tx_workThe skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup failswith a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: leds: fix memory leakA network restart test on a router led to an out-of-memory condition,which was traced to a memory leak in the PHY LED trigger code.The root cause is misuse of the devm API. The registration function(phy_led_triggers_register) is called from phy_attach_direct, notphy_probe, and the unregister function (phy_led_triggers_unregister)is called from phy_detach, not phy_remove. This means the register andunregister functions can be called multiple times for the same PHYdevice, but devm-allocated memory is not freed until the driver isunbound.This also prevents kmemleak from detecting the leak, as the devm APIinternally stores the allocated pointer.Fix this by replacing devm_kzalloc/devm_kcalloc with standardkzalloc/kcalloc, and add the corresponding kfree calls in the unregisterpath.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Flush gso_skb list too during ->change()Previously, when reducing a qdisc's limit via the ->change() operation, onlythe main skb queue was trimmed, potentially leaving packets in the gso_skblist. This could result in NULL pointer dereference when we only checksch->limit against sch->q.qlen.This patch introduces a new helper, qdisc_dequeue_internal(), which ensuresboth the gso_skb list and the main queue are properly flushed when trimmingexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)are updated to use this helper in their ->change() routines.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: handle failure of nfs_get_lock_context in unlock pathWhen memory is insufficient, the allocation of nfs_lock_context innfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treatan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)as valid and proceed to execute rpc_run_task(), this will trigger a NULLpointer dereference in nfs4_locku_prepare. For example:BUG: kernel NULL pointer dereference, address: 000000000000000cPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40Workqueue: rpciod rpc_async_scheduleRIP: 0010:nfs4_locku_prepare+0x35/0xc2Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in:CR2: 000000000000000c---[ end trace 0000000000000000 ]---Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails andreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointerdereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bugCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fIn the function rxe_create_cq, when rxe_cq_from_init fails, the functionrxe_cleanup will be called to handle the allocated resources. In fact,some memory resources have already been freed in the functionrxe_cq_from_init. Thus, this problem will occur.The solution is to let rxe_cleanup do all the work.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free in cifs_fill_direntThere is a race condition in the readdir concurrency process, which mayaccess the rsp buffer after it has been released, triggering thefollowing KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================POC is available in the link [1].The problem triggering process is as follows:Process 1 Process 2--------------------------------------truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libnvdimm/labels: Fix divide error in nd_label_data_init()If a faulty CXL memory device returns a broken zero LSA size in itsmemory device information (Identify Memory Device (Opcode 4000h), CXLspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimmdriver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]Code and flow:1) CXL Command 4000h returns LSA size = 02) config_size is assigned to zero LSA size (CXL pmem driver):drivers/cxl/pmem.c: .config_size = mds->lsa_size,3) max_xfer is set to zero (nvdimm driver):drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);4) A subsequent DIV_ROUND_UP() causes a division by zero:drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,drivers/nvdimm/label.c- config_size);Fix this by checking the config size parameter by extending anexisting check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vhost-scsi: protect vq->log_used with vq->mutexThe vhost-scsi completion path may access vq->log_base when vq->log_used isalready set to false. vhost-thread QEMU-threadvhost_scsi_complete_cmd_work()-> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base)Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can bereclaimed via gfree(). As a result, this causes invalid memory writes toQEMU userspace.The control queue path has the same issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix timeout on deleted connectionNOPIN response timer may expire on a deleted connection and crash withsuch logs:Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3dBUG: Kernel NULL pointer dereference on read at 0x00000000NIP strlcpy+0x8/0xb0LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410That is because nopin response timer may be re-started on nopin timerexpiration.Stop nopin timer before stopping the nopin response timer to be surethat no one of them will be re-started.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix race of buffer access at PCM OSS layerThe PCM OSS layer tries to clear the buffer with the silence data atinitialization (or reconfiguration) of a stream with the explicit callof snd_pcm_format_set_silence() with runtime->dma_area. But this maylead to a UAF because the accessed runtime->dma_area might be freedconcurrently, as it's performed outside the PCM ops.For avoiding it, move the code into the PCM core and perform it insidethe buffer access lock, so that it won't be changed during theoperation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: cadence: macb: Fix a possible deadlock in macb_halt_tx.There is a situation where after THALT is set high, TGO stays high aswell. Because jiffies are never updated, as we are in a context withinterrupts disabled, we never exit that loop and have a deadlock.That deadlock was noticed on a sama5d4 device that stayed locked for days.Use retries instead of jiffies so that the timeout really works and we donot have a deadlock anymore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: fix a potential crash on gso_skb handlingSFQ has an assumption of always being able to queue at least one packet.However, after the blamed commit, sch->q.len can be inflated by packetsin sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followedby an immediate drop.Fix sfq_drop() to properly clear q->tail in this situation.ip netns add lbip link add dev to-lb type veth peer name in-lb netns lbethtool -K to-lb tso off # force qdisc to requeue gso_skbip netns exec lb ethtool -K in-lb gro on # enable NAPIip link set dev to-lb upip -netns lb link set dev in-lb upip addr add dev to-lb 192.168.20.1/24ip -netns lb addr add dev in-lb 192.168.20.2/24tc qdisc replace dev to-lb root sfq limit 100ip netns exec lb netservernetperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: add missing NULL check for gve_alloc_pending_packet() in TX DQOgve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()did not check for this case before dereferencing the returned pointer.Add a missing NULL check to prevent a potential NULL pointerdereference when allocation fails.This improves robustness in low-memory scenarios.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Don't call calipso functions for AF_INET sk.syzkaller reported a null-ptr-deref in txopt_get(). [0]The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,so struct ipv6_pinfo was NULL there.However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6is always set in inet6_create(), meaning the socket was not IPv6 one.The root cause is missing validation in netlbl_conn_setattr().netlbl_conn_setattr() switches branches based on structsockaddr.sa_family, which is passed from userspace. However,netlbl_conn_setattr() does not check if the address family matchesthe socket.The syzkaller must have called connect() for an IPv6 address onan IPv4 socket.We have a proper validation in tcp_v[46]_connect(), butsecurity_socket_connect() is called in the earlier stage.Let's copy the validation to netlbl_conn_setattr().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]RIP: 0010:Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00cRDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9eR10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0PKRU: 80000000Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f901b61a12dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12dRDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearerThe reproduction steps:1. create a tun interface2. enable l2 bearer3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tuntipc: Started in network modetipc: Node identity 8af312d38a21, cluster identity 4711tipc: Enabled bearer , priority 1Oops: general protection faultKASAN: null-ptr-deref in rangeCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPTHardware name: QEMU Ubuntu 24.04 PCRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0the ub was in fact a struct dev.when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL orother media when other thread changes it.fix this by checking media_id.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Free invalid length skb in atmtcp_c_send().syzbot reported the splat below. [0]vcc_sendmsg() copies data passed from userspace to skb and passesit to vcc->dev->ops->send().atmtcp_c_send() accesses skb->data as struct atmtcp_hdr afterchecking if skb->len is 0, but it's not enough.Also, when skb->len == 0, skb and sk (vcc) were leaked becausedev_kfree_skb() is not called and sk_wmem_alloc adjustment is missingto revert atm_account_tx() in vcc_sendmsg(), which is expectedto be done in atm_pop_raw().Let's properly free skb with an invalid length in atmtcp_c_send().[0]:BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Revert atm_account_tx() if copy_from_iter_full() fails.In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc byatm_account_tx().It is expected to be reverted by atm_pop_raw() later called byvcc->dev->ops->send(vcc, skb).However, vcc_sendmsg() misses the same revert when copy_from_iter_full()fails, and then we will leak a socket.Let's factorise the revert part as atm_return_tx() and call it inthe failure path.Note that the corresponding sk_wmem_alloc operation can be found inalloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Make sure modelist not set on unregistered consoleIt looks like attempting to write to the "store_modes" sysfs node willrun afoul of unregistered consoles:UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28index -1 is out of range for type 'fb_info *[32]'... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439static struct fb_info *fbcon_registered_fb[FB_MAX];...static signed char con2fb_map[MAX_NR_CONSOLES];...static struct fb_info *fbcon_info_from_console(int console)... return fbcon_registered_fb[con2fb_map[console]];If con2fb_map contains a -1 things go wrong here. Instead, return NULL,as callers of fbcon_info_from_console() are trying to compare againstexisting "info" pointers, so error handling should kick in correctly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in fb_set_var() fails to allocate memory forfb_videomode, later it may lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================The reason is that fb_info->var is being modified in fb_set_var(), andthen fb_videomode_to_var() is called. If it fails to add the mode tofb_info->modelist, fb_set_var() returns error, but does not restore theold value of fb_info->var. Restore fb_info->var on failure the same wayit is done earlier in the function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix NULL pointer in cache_set_flush()1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc().2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set().3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 }(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885).(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL.LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().As (1), in LINE#1885 callbch_cache_set_unregister()---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 }(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below:[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory[ 846.713242] bcache: register_bcache() error : failed to register device[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8[ 846.714790] PGD 0 P4D 0[ 846.715129] Oops: 0000 [#1] SMP PTI[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018[ 846.716451] Workqueue: events cache_set_flush [bcache][ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache][ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix double-free on mc_devThe blamed commit tried to simplify how the deallocations are done but,in the process, introduced a double-free on the mc_dev variable.In case the MC device is a DPRC, a new mc_bus is allocated and themc_dev variable is just a reference to one of its fields. In thiscircumstance, on the error path only the mc_bus should be freed.This commit introduces back the following checkpatch warning which is afalse-positive.WARNING: kfree(NULL) is safe and this check is probably not required+ if (mc_bus)+ kfree(mc_bus);
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_tableThe function atomctrl_initialize_mc_reg_table() andatomctrl_initialize_mc_reg_table_v2_2() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()fails to retrieve vram_info, it returns NULL which is laterdereferenced.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()Since handle->h_transaction may be a NULL pointer, so we should change itto call is_handle_aborted(handle) first before dereferencing it.And the following data-race was reported in my fuzzer:==================================================================BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadatawrite to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....value changed: 0x00000000 -> 0x00000001==================================================================This issue is caused by missing data-race annotation for jh->b_modified.Therefore, the missing annotation needs to be added.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check dce_hwseq before dereferencing it[WHAT]hws was checked for null earlier in dce110_blank_stream, indicating hwscan be null, and should be checked whenever it is used.(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Refuse to evaluate a method if arguments are missingAs reported in [1], a platform firmware update that increased the numberof method parameters and forgot to update a least one of its callers,caused ACPICA to crash due to use-after-free.Since this a result of a clear AML issue that arguably cannot be fixedup by the interpreter (it cannot produce missing data out of thin air),address it by making ACPICA refuse to evaluate a method if the callerattempts to pass fewer arguments than expected to it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: do not ping device which has failed to load firmwareSyzkaller reports [1, 2] crashes caused by an attempts to pingthe device which has failed to load firmware. Since such a devicedoesn't pass 'ieee80211_register_hw()', an internal workqueuemanaged by 'ieee80211_queue_work()' is not yet created and anattempt to queue work on it causes null-ptr-deref.[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix sample vs do_exit()Baisheng Gao reported an ARM64 crash, which Mark decoded as being asynchronous external abort -- most likely due to trying to accessMMIO in bad ways.The crash further shows perf trying to do a user stack sample while inexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the addressspace it is trying to access.It turns out that we stop perf after we tear down the userspace mm; areceipie for disaster, since perf likes to access userspace forvarious reasons.Flip this order by moving up where we stop perf in do_exit().Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USERto abort when the current task does not have an mm (exit_mm() makessure to set current->mm = NULL; before commencing with the actualteardown). Such that CPU wide events don't trip on this same problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: nfsd4_spo_must_allow() must check this is a v4 compound requestIf the request being processed is not a v4 compound request, thenexamining the cstate can have undefined results.This patch adds a check that the rpc procedure being executed(rq_procinfo) is the NFSPROC4_COMPOUND procedure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Abort __tc_modify_qdisc if parent class does not existLion's patch [1] revealed an ancient bug in the qdisc API.Whenever a user creates/modifies a qdisc specifying as a parent anotherqdisc, the qdisc API will, during grafting, detect that the user isnot trying to attach to a class and reject. However grafting isperformed after qdisc_create (and thus the qdiscs' init callback) isexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlogduring init or change (such as fq, hhf, choke, etc), an issuearises. For example, executing the following commands:sudo tc qdisc add dev lo root handle a: htb default 2sudo tc qdisc add dev lo parent a: handle beef fqQdiscs such as fq, hhf, choke, etc unconditionally invokeqdisc_tree_reduce_backlog() in their control path init() or change() whichthen causes a failure to find the child class; however, that does not stopthe unconditional invocation of the assumed child qdisc's qlen_notify witha null class. All these qdiscs make the assumption that class is non-null.The solution is ensure that qdisc_leaf() which looks up the parentclass, and is invoked prior to qdisc_create(), should return failure onnot finding the class.In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever theparentid doesn't correspond to a class, so that we can detect itearlier on and abort before qdisc_create is called.[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix wraparounds of sk->sk_rmem_alloc.Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc);, which has the same problem fixed by commit 5a465a0da13e ("udp:Fix multiple wraparounds of sk->sk_rmem_alloc.").For example, if we set INT_MAX to SO_RCVBUFFORCE, the conditionis always false as the two operands are of int.Then, a single socket can eat as many skb as possible until OOMhappens, and we can see multiple wraparounds of sk->sk_rmem_alloc.Let's fix it by using atomic_add_return() and comparing the twovariables as unsigned int.Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 *After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtreehtb_lookup_leaf has a BUG_ON that can trigger with the following:tc qdisc del dev lo roottc qdisc add dev lo root handle 1: htb default 1tc class add dev lo parent 1: classid 1:1 htb rate 64bittc qdisc add dev lo parent 1:1 handle 2: netemtc qdisc add dev lo parent 2:1 handle 3: blackholeping -I lo -c1 -W0.001 127.0.0.1The root cause is the following:1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc2. netem_dequeue calls enqueue on the child qdisc3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ONThe function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------The full original bug report can be seen here [1].We can fix this just by returning NULL instead of the BUG_ON,as htb_dequeue_tree returns NULL when htb_lookup_leaf returnsNULL.[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtimeAssuming the "rx-vlan-filter" feature is enabled on a net device, the8021q module will automatically add or remove VLAN 0 when the net deviceis put administratively up or down, respectively. There are a couple ofproblems with the above scheme.The first problem is a memory leak that can happen if the "rx-vlan-filter"feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1When the device is put administratively down the "rx-vlan-filter"feature is disabled, so the 8021q module will not remove VLAN 0 and thememory will be leaked [1].Another problem that can happen is that the kernel can automaticallydelete VLAN 0 when the device is put administratively down despite notadding it when the device was put administratively up since during thattime the "rx-vlan-filter" feature was disabled. null-ptr-unref orbug_on[2] will be triggered by unregister_vlan_dev() for refcountimbalance if toggling filtering during runtime:$ ip link add bond0 type bond mode 0$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q$ ethtool -K bond0 rx-vlan-filter off$ ifconfig bond0 up$ ethtool -K bond0 rx-vlan-filter on$ ifconfig bond0 down$ ip link del vlan0Root cause is as below:step1: add vlan0 for real_dev, such as bond, team.register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1step2: disable vlan filter feature and enable real_devstep3: change filter from 0 to 1vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0step4: real_dev downvlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0step5: delete vlan0unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is nullFix both problems by noting in the VLAN info whether VLAN 0 wasautomatically added upon NETDEV_UP and based on that decide whether itshould be deleted upon NETDEV_DOWN, regardless of the state of the"rx-vlan-filter" feature.[1]unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180[2]kernel BUG at net/8021q/vlan.c:99!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))RSP: 0018:ffff88810badf310 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9aRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017eFS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0Call Trace:
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: net: sierra: check for no status endpointThe driver checks for having three endpoints andhaving bulk in and out endpoints, but not thatthe third endpoint is interrupt input.Rectify the omission.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix oops due to non-existence of prealloc backlog structIf an AF_RXRPC service socket is opened and bound, but calls arepreallocated, then rxrpc_alloc_incoming_call() will oops because therxrpc_backlog struct doesn't get allocated until the first preallocation ismade.Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is nobacklog struct. This will cause the incoming call to be aborted.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Restrict conditions for adding duplicating netems to qdisc treenetem_enqueue's duplication prevention logic breaks when a netemresides in a qdisc tree with other netems - this can lead to asoft lockup and OOM loop in netem_dequeue, as seen in [1].Ensure that a duplicating netem cannot exist in a tree with othernetems.Previous approaches suggested in discussions in chronological order:1) Track duplication status or ttl in the sk_buff struct. Consideredtoo specific a use case to extend such a struct, though this wouldbe a resilient fix and address other previous and potential futureDOS bugs like the one described in loopy fun [2].2) Restrict netem_enqueue recursion depth like in act_mirred with aper cpu variable. However, netem_dequeue can call enqueue on itschild, and the depth restriction could be bypassed if the child is anetem.3) Use the same approach as in 2, but add metadata in netem_skb_cbto handle the netem_dequeue case and track a packet's involvementin duplication. This is an overly complex approach, and Jamalnotes that the skb cb can be overwritten to circumvent thissafeguard.4) Prevent the addition of a netem to a qdisc tree if its ancestralpath contains a netem. However, filters and actions can cause apacket to change paths when re-enqueued to the root from netemduplication, leading us to the current solution: prevent aduplicating netem from inhabiting the same tree as other netems.[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/[2] https://lwn.net/Articles/719297/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iwlwifi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue since it mayreturn NULL pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Clean up allocated IRQs on unplugWhen the root of a nested PCIe bridge configuration is unplugged, thepnv_php driver leaked the allocated IRQ resources for the child bridges'hotplug event notifications, resulting in a panic.Fix this by walking all child buses and deallocating all its IRQ resourcesbefore calling pci_hp_remove_devices().Also modify the lifetime of the workqueue at struct pnv_php_slot::wq sothat it is only destroyed in pnv_php_free_slot(), instead ofpnv_php_disable_irq(). This is required since pnv_php_disable_irq() willnow be called by workers triggered by hot unplug interrupts, so theworkqueue needs to stay allocated.The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec[bhelgaas: tidy comments]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_modeAndrei Lalaev reported a NULL pointer deref when a CAN device isrestarted from Bus Off and the driver does not implement the structcan_priv::do_set_mode callback.There are 2 code path that call struct can_priv::do_set_mode:- directly by a manual restart from the user space, via can_changelink()- delayed automatic restart after bus off (deactivated by default)To prevent the NULL pointer deference, refuse a manual restart orconfigure the automatic restart delay in can_changelink() and reportthe error via extack to user space.As an additional safety measure let can_restart() return an error ifcan_priv::do_set_mode is not set instead of dereferencing itunchecked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Fix OOB read due to missing payload bound checkCurrently, The event_seq_changed() handler processes a variable numberof properties sent by the firmware. The number of properties is indicatedby the firmware and used to iterate over the payload. However, thepayload size is not being validated against the actual message length.This can lead to out-of-bounds memory access if the firmware provides aproperty count that exceeds the data available in the payload. Such acondition can result in kernel crashes or potential information leaks ifmemory beyond the buffer is accessed.Fix this by properly validating the remaining size of the payload beforeeach property access and updating bounds accordingly as properties areparsed.This ensures that property parsing is safely bounded within the receivedmessage buffer and protects against malformed or malicious firmwarebehavior.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()The buffer length check before calling uvc_parse_format() only ensuredthat the buffer has at least 3 bytes (buflen > 2), buf the functionaccesses buffer[3], requiring at least 4 bytes.This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.Fix it by checking that the buffer has at least 4 bytes inuvc_parse_format().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix race between polling and detachingsyzbot reports a use-after-free in comedi in the below link, which isdue to comedi gladly removing the allocated async area even though pollrequests are still active on the wait_queue_head inside of it. This cancause a use-after-free when the poll entries are later triggered orremoved, as the memory for the wait_queue_head has been freed. We needto check there are no tasks queued on any of the subdevices' wait queuesbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`ioctl.Tasks will read-lock `dev->attach_lock` before adding themselves to thesubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctlhandler by write-locking `dev->attach_lock` before checking that all ofthe subdevices are safe to be deleted. This includes testing for anysleepers on the subdevices' wait queues. It remains locked until thedevice has been detached. This requires the `comedi_device_detach()`function to be refactored slightly, moving the bulk of it into newfunction `comedi_device_detach_locked()`.Note that the refactor of `comedi_device_detach()` results in`comedi_device_cancel_all()` now being called while `dev->attach_lock`is write-locked, which wasn't the case previously, but that does notmatter.Thanks to Jens Axboe for diagnosing the problem and co-developing thispatch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix uninited ptr deref in block/scsi layoutThe error occurs on the third attempt to encode extents. When functionext_tree_prepare_commit() reallocates a larger buffer to retry encodingextents, the "layoutupdate_pages" page array is initialized only after theretry loop. But ext_tree_free_commitdata() is called on every iterationand tries to put pages in the array, thus dereferencing uninitializedpointers.An additional problem is that there is no limit on the maximum possiblebuffer_size. When there are too many extents, the client may create alayoutcommit that is larger than the maximum possible RPC size acceptedby the server.During testing, we observed two typical scenarios. First, one memory pagefor extents is enough when we work with small files, append data to theend of the file, or preallocate extents before writing. But when we filla new large file without preallocating, the number of extents can be huge,and counting the number of written extents in ext_tree_encode_commit()does not help much. Since this number increases even more betweenunlocking and locking of ext_tree, the reallocated buffer may not belarge enough again and again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix null pointer accessWriting a string without delimiters (' ', '\n', '\0') to the undergpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profilewill result in a null pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()When the volume header contains erroneous values that do not reflectthe actual state of the filesystem, hfsplus_fill_super() assumes thatthe attributes file is not yet created, which later results in hittingBUG_ON() when hfsplus_create_attributes_file() is called. Replace thisBUG_ON() with -EIO error with a message to suggest running fsck tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix refcount leak on table dumpThere is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...While its very unlikely, its possible that ct == last.If this happens, then the refcount of ct was already incremented.This 2nd increment is never undone.This prevents the conntrack object from being released, which in turnkeeps prevents cnet->count from dropping back to 0.This will then block the netns dismantle (or conntrack rmmod) asnf_conntrack_cleanup_net_list() will wait forever.This can be reproduced by running conntrack_resize.sh selftest in a loop.It takes ~20 minutes for me on a preemptible kernel on average beforeI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);But this reference counting isn't needed in the first place.We can just store a cookie value instead.A followup patch will do the same for ctnetlink_exp_dump_table,it looks to me as if this has the same problem and likectnetlink_dump_table, we only need a 'skip hint', not the actualobject so we can apply the same cookie strategy there as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()Lei Lu recently reported that nfsd4_setclientid_confirm() did not checkthe return value from get_client_locked(). a SETCLIENTID_CONFIRM couldrace with a confirmed client expiring and fail to get a reference. Thatcould later lead to a UAF.Fix this by getting a reference early in the case where there is anextant confirmed client. If that fails then treat it as if there were noconfirmed client found at all.In the case where the unconfirmed client is expiring, just fail andreturn the result from get_client_locked().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: avoid infinite retry looping in netlink_unicast()netlink_attachskb() checks for the socket's read memory allocationconstraints. Firstly, it has: rmem < READ_ONCE(sk->sk_rcvbuf)to check if the just increased rmem value fits into the socket's receivebuffer. If not, it proceeds and tries to wait for the memory under: rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)The checks don't cover the case when skb->truesize + sk->sk_rmem_alloc isequal to sk->sk_rcvbuf. Thus the function neither successfully acceptsthese conditions, nor manages to reschedule the task - and is called inretry loop for indefinite time which is caught as: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: dump_stack lib/dump_stack.c:120 nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105 nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62 rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335 rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590 update_process_times kernel/time/timer.c:1953 tick_sched_handle kernel/time/tick-sched.c:227 tick_sched_timer kernel/time/tick-sched.c:1399 __hrtimer_run_queues kernel/time/hrtimer.c:1652 hrtimer_interrupt kernel/time/hrtimer.c:1717 __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113 asm_call_irq_on_stack arch/x86/entry/entry_64.S:808 netlink_attachskb net/netlink/af_netlink.c:1234 netlink_unicast net/netlink/af_netlink.c:1349 kauditd_send_queue kernel/audit.c:776 kauditd_thread kernel/audit.c:897 kthread kernel/kthread.c:328 ret_from_fork arch/x86/entry/entry_64.S:304Restore the original behavior of the check which commit in Fixesaccidentally missed when restructuring the code.Found by Linux Verification Center (linuxtesting.org).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 power domain descriptors, tooUAC3 power domain descriptors need to be verified with its variablebLength for avoiding the unexpected OOB accesses by maliciousfirmware, too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: prevent ethtool ops after shutdownA crash can occur if an ethtool operation is invokedafter shutdown() is called.shutdown() is invoked during system shutdown to stop DMA operationswithout performing expensive deallocations. It is discouraged tounregister the netdev in this path, so the device may still be visibleto userspace and kernel helpers.In gve, shutdown() tears down most internal data structures. If anethtool operation is dispatched after shutdown(), it will dereferencefreed or NULL pointers, leading to a kernel panic. While gracefulshutdown normally quiesces userspace before invoking the rebootsyscall, forced shutdowns (as observed on GCP VMs) can still triggerthis path.Fix by calling netif_device_detach() in shutdown().This marks the device as detached so the ethtool ioctl handlerwill skip dispatching operations to the driver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix backlog accounting in qdisc_dequeue_internalThis issue applies for the following qdiscs: hhf, fq, fq_codel, andfq_pie, and occurs in their change handlers when adjusting to the newlimit. The problem is the following in the values passed to thesubsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).To fix this issue, the codepath for all clients of qdisc_dequeue_internalhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.qdisc_dequeue_internal handles the backlog adjustments for all cases thatdo not directly use the dequeue handler.The old fq_codel_change limit adjustment loop accumulated the arguments tothe subsequent qdisc_tree_reduce_backlog call through the cstats field.However, this is confusing and error prone as fq_codel_dequeue could alsopotentially mutate this field (which qdisc_dequeue_internal calls in thenon gso_skb case), so we have unified the code here with other qdiscs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernelbuffer is allocated to hold `insn->n` samples (each of which is an`unsigned int`). For some instruction types, `insn->n` samples arecopied back to user-space, unless an error code is being returned. Theproblem is that not all the instruction handlers that need to returndata to userspace fill in the whole `insn->n` samples, so that there isan information leak. There is a similar syzbot report for`do_insnlist_ioctl()`, although it does not have a reproducer for it atthe time of writing.One culprit is `insn_rw_emulate_bits()` which is used as the handler for`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not havea specific handler for that instruction, but do have an `INSN_BITS`handler. For `INSN_READ` it only fills in at most 1 sample, so if`insn->n` is greater than 1, the remaining `insn->n - 1` samples copiedto userspace will be uninitialized kernel data.Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. Itnever returns an error, even if it fails to fill the buffer.Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making surethat uninitialized parts of the allocated buffer are zeroed beforehandling each instruction.Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fixreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is notalways necessary to clear the whole buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Make insn_rw_emulate_bits() do insn->n samplesThe `insn_rw_emulate_bits()` function is used as a default handler for`INSN_READ` instructions for subdevices that have a handler for`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a defaulthandler for `INSN_WRITE` instructions for subdevices that have a handlerfor `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the`INSN_READ` or `INSN_WRITE` instruction handling with a constructed`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`instructions are supposed to be able read or write multiple samples,indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currentlyonly handles a single sample. For `INSN_READ`, the comedi core willcopy `insn->n` samples back to user-space. (That triggered KASANkernel-infoleak errors when `insn->n` was greater than 1, but that isbeing fixed more generally elsewhere in the comedi core.)Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or returnan error, to conform to the general expectation for `INSN_READ` and`INSN_WRITE` handlers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix a Null pointer dereference vulnerability[Why]A null pointer dereference vulnerability exists in the AMD display driver's(DC module) cleanup function dc_destruct().When display control context (dc->ctx) construction fails(due to memory allocation failure), this pointer remains NULL.During subsequent error handling when dc_destruct() is called,there's no NULL check before dereferencing the perf_trace member(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.[How]Check if dc->ctx is non-NULL before dereferencing.(Updated commit text and removed unnecessary error message)(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: fix panic due to PSLVERRWhen the PSLVERR_RESP_EN parameter is set to 1, the device generatesan error response if an attempt is made to read an empty RBR (ReceiveBuffer Register) while the FIFO is enabled.In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokesdw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latterfunction enables the FIFO via serial_out(p, UART_FCR, p->fcr).Execution proceeds to the serial_port_in(port, UART_RX).This satisfies the PSLVERR trigger condition.When another CPU (e.g., using printk()) is accessing the UART (UARTis busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enterdw8250_force_idle().Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lockto fix this issue.Panic backtrace:[ 0.442336] Oops - unknown exception [#1][ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e...[ 0.442416] console_on_rootfs+0x26/0x70
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ism: fix concurrency management in ism_cmd()The s390x ISM device data sheet clearly states that only onerequest-response sequence is allowable per ISM function at any point intime. Unfortunately as of today the s390/ism driver in Linux does nothonor that requirement. This patch aims to rectify that.This problem was discovered based on Aliaksei's bug report which statesthat for certain workloads the ISM functions end up entering error state(with PEC 2 as seen from the logs) after a while and as a consequenceconnections handled by the respective function break, and for futureconnection requests the ISM device is not considered -- given it is in adysfunctional state. During further debugging PEC 3A was observed aswell.A kernel message like[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61ais a reliable indicator of the stated function entering error statewith PEC 2. Let me also point out that a kernel message like[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recoveryis a reliable indicator that the ISM function won't be auto-recoveredbecause the ISM driver currently lacks support for it.On a technical level, without this synchronization, commands (inputs tothe FW) may be partially or fully overwritten (corrupted) by another CPUtrying to issue commands on the same function. There is hard evidence thatthis can lead to DMB token values being used as DMB IOVAs, leading toPEC 2 PCI events indicating invalid DMA. But this is only one of thefailure modes imaginable. In theory even completely losing one commandand executing another one twice and then trying to interpret the outputsas if the command we intended to execute was actually executed and notthe other one is also possible. Frankly, I don't feel confident aboutproviding an exhaustive list of possible consequences.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/smaps: fix race between smaps_hugetlb_range and migrationsmaps_hugetlb_range() handles the pte without holdling ptl, and may beconcurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). The race is as follows.smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ONTo fix it, hold ptl lock in smaps_hugetlb_range().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 cluster segment descriptorsUAC3 class segment descriptors need to be verified whether their sizesmatch with the declared lengths and whether they fit with theallocated buffer sizes, too. Otherwise malicious firmware may lead tothe unexpected OOB accesses.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: remove refcounting in expectation dumpersSame pattern as previous patch: do not keep the expectation objectalive via refcount, only store a cookie value and then use thatas the skip hint for dump resumption.AFAICS this has the same issue as the one resolved in the conntrackdumper, when we do if (!refcount_inc_not_zero(&exp->use))to increment the refcount, there is a chance that exp == last, whichcauses a double-increment of the refcount and subsequent memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/hisilicon/hibmc: fix the hibmc loaded failed bugWhen hibmc loaded failed, the driver use hibmc_unload to free theresource, but the mutexes in mode.config are not init, which willaccess an NULL pointer. Just change goto statement to return, becausehibnc_hw_init() doesn't need to free anything.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix soft lockup in br_multicast_query_expired()When set multicast_query_interval to a large value, the local variable'time' in br_multicast_send_query() may overflow. If the time is smallerthan jiffies, the timer will expire immediately, and then call mod_timer()again, which creates a loop and may trigger the following soft lockupissue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 upThe multicast_startup_query_interval can also cause this issue. Similar tothe commit 99b40610956a ("net: bridge: mcast: add and enforce queryinterval minimum"), add check for the query interval maximum to fix thisissue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: prevent softlockup in jbd2_log_do_checkpoint()Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()periodically release j_list_lock after processing a batch of buffers toavoid long hold times on the j_list_lock. However, since both functionscontend for j_list_lock, the combined time spent waiting and processingcan be significant.jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() whenneed_resched() is true to avoid softlockups during prolonged operations.But jbd2_log_do_checkpoint() only exits its loop when need_resched() istrue, relying on potentially sleeping functions like __flush_batch() orwait_on_buffer() to trigger rescheduling. If those functions do not sleep,the kernel may hit a softlockup.watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017Workqueue: writeback wb_workfn (flush-7:2)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : native_queued_spin_lock_slowpath+0x358/0x418lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoidsoftlockup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()If we find an unexpected generation for the extent buffer we are cloningat btrfs_copy_root(), we just WARN_ON() and don't error out and abort thetransaction, meaning we allow to persist metadata with an unexpectedgeneration. Instead of warning only, abort the transaction and return-EUCLEAN.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()in ntrig_report_version(), hdev parameter passed from hid_probe().sending descriptor to /dev/uhid can make hdev->dev.parent->parent to nullif hdev->dev.parent->parent is null, usb_dev hasinvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returnedwhen usb_rcvctrlpipe() use usb_dev,it triggerpage fault error for address(0xffffffffffffff58)add null check logic to ntrig_report_version()before calling hid_to_usb_dev()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: asus: fix UAF via HID_CLAIMED_INPUT validationAfter hid_hw_start() is called hidinput_connect() will eventually becalled to set up the device with the input layer since theHID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()all input and output reports are processed and corresponding hid_inputsare allocated and configured via hidinput_configure_usages(). Thisprocess involves slot tagging report fields and configuring usagesby setting relevant bits in the capability bitmaps. However it is possiblethat the capability bitmaps are not set at all leading to the subsequenthidinput_has_been_populated() check to fail leading to the freeing of thehid_input and the underlying input device.This becomes problematic because a malicious HID device like aASUS ROG N-Key keyboard can trigger the above scenario via aspecially crafted descriptor which then leads to a user-after-freewhen the name of the freed input device is written to later on afterhid_hw_start(). Below, report 93 intentionally utilises theHID_UP_UNDEFINED Usage Page which is skipped during usageconfiguration, leading to the frees.0x05, 0x0D, // Usage Page (Digitizer)0x09, 0x05, // Usage (Touch Pad)0xA1, 0x01, // Collection (Application)0x85, 0x0D, // Report ID (13)0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)0x09, 0xC5, // Usage (0xC5)0x15, 0x00, // Logical Minimum (0)0x26, 0xFF, 0x00, // Logical Maximum (255)0x75, 0x08, // Report Size (8)0x95, 0x04, // Report Count (4)0xB1, 0x02, // Feature (Data,Var,Abs)0x85, 0x5D, // Report ID (93)0x06, 0x00, 0x00, // Usage Page (Undefined)0x09, 0x01, // Usage (0x01)0x15, 0x00, // Logical Minimum (0)0x26, 0xFF, 0x00, // Logical Maximum (255)0x75, 0x08, // Report Size (8)0x95, 0x1B, // Report Count (27)0x81, 0x02, // Input (Data,Var,Abs)0xC0, // End CollectionBelow is the KASAN splat after triggering the UAF:[ 21.672709] ==================================================================[ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80[ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54[ 21.673700][ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)[ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014[ 21.673700] Call Trace:[ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80[ 21.673700] print_report+0xd1/0x660[ 21.673700] kasan_report+0xe5/0x120[ 21.673700] __asan_report_store8_noabort+0x1b/0x30[ 21.673700] asus_probe+0xeeb/0xf80[ 21.673700] hid_device_probe+0x2ee/0x700[ 21.673700] really_probe+0x1c6/0x6b0[ 21.673700] __driver_probe_device+0x24f/0x310[ 21.673700] driver_probe_device+0x4e/0x220[...][ 21.673700][ 21.673700] Allocated by task 54:[ 21.673700] kasan_save_stack+0x3d/0x60[ 21.673700] kasan_save_track+0x18/0x40[ 21.673700] kasan_save_alloc_info+0x3b/0x50[ 21.673700] __kasan_kmalloc+0x9c/0xa0[ 21.673700] __kmalloc_cache_noprof+0x139/0x340[ 21.673700] input_allocate_device+0x44/0x370[ 21.673700] hidinput_connect+0xcb6/0x2630[ 21.673700] hid_connect+0xf74/0x1d60[ 21.673700] hid_hw_start+0x8c/0x110[ 21.673700] asus_probe+0x5a3/0xf80[ 21.673700] hid_device_probe+0x2ee/0x700[ 21.673700] really_probe+0x1c6/0x6b0[ 21.673700] __driver_probe_device+0x24f/0x310[ 21.673700] driver_probe_device+0x4e/0x220[...][ 21.673700][ 21.673700] Freed by task 54:[ 21.673700] kasan_save_stack+0x3d/0x60[ 21.673700] kasan_save_track+0x18/0x40[ 21.673700] kasan_save_free_info+0x3f/0x60[ 21.673700] __kasan_slab_free+0x3c/0x50[ 21.673700] kfre---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix memory leak in pad_compress_skbIf alloc_skb() fails in pad_compress_skb(), it returns NULL withoutreleasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop;drop: kfree_skb(skb);When pad_compress_skb() returns NULL, the reference to the old skb islost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.Align pad_compress_skb() semantics with realloc(): only free the oldskb if allocation and compression succeed. At the call site, use thenew_skb variable so the original skb is not lost when pad_compress_skb()fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix potential invalid access when MAC list is emptylist_first_entry() never returns NULL - if the list is empty, it stillreturns a pointer to an invalid object, leading to potential invalidmemory access when dereferenced.Fix this by using list_first_entry_or_null instead of list_first_entry.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()syzbot reported the splat below without a repro.In the splat, a single thread calling bt_accept_dequeue() freed skand touched it after that.The root cause would be the racy l2cap_sock_cleanup_listen() calladded by the cited commit.bt_accept_dequeue() is called under lock_sock() except forl2cap_sock_release().Two threads could see the same socket during the list iterationin bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAFDepending on the timing, the other thread could show up in the"Freed by task" part.Let's call l2cap_sock_cleanup_listen() under lock_sock() inl2cap_sock_release().[0]:BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2accf8ebe9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166fR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609cR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info workThe brcmf_btcoex_detach() only shuts down the btcoex timer, if theflag timer_on is false. However, the brcmf_btcoex_timerfunc(), whichruns as timer handler, sets timer_on to false. This creates criticalrace conditions:1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()is executing, it may observe timer_on as false and skip the call totimer_shutdown_sync().2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_infoworker after the cancel_work_sync() has been executed, resulting inuse-after-free bugs.The use-after-free bugs occur in two distinct scenarios, depending onthe timing of when the brcmf_btcoex_info struct is freed relative tothe execution of its worker thread.Scenario 1: Freed before the worker is scheduledThe brcmf_btcoex_info is deallocated before the worker is scheduled.A race condition can occur when schedule_work(&bt_local->work) iscalled after the target memory has been freed. The sequence of eventsis detailed below:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USEScenario 2: Freed after the worker is scheduledThe brcmf_btcoex_info is freed after the worker has been scheduledbut before or during its execution. In this case, statements withinthe brcmf_btcoex_handler() - such as the container_of macro andsubsequent dereferences of the brcmf_btcoex_info object will causea use-after-free access. The following timeline illustrates thisscenario:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ |To resolve the race conditions, drop the conditional check and calltimer_shutdown_sync() directly. It can deactivate the timer reliably,regardless of its current state. Once stopped, the timer_on state isthen set to false.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tee: fix NULL pointer dereference in tee_shm_puttee_shm_put have NULL pointer dereference:__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crashAdd check in tee_shm_put to fix it.panic log:Unable to handle kernel paging request at virtual address 0000000000100ccaMem abort info:ESR = 0x0000000096000004EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x04: level 0 translation faultData abort info:ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----6.6.0-39-generic #38Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.010/26/2022pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : tee_shm_put+0x24/0x188lr : tee_shm_free+0x14/0x28sp : ffff001f98f9faf0x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffffx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0cx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100ccaCall trace:tee_shm_put+0x24/0x188tee_shm_free+0x14/0x28__optee_disable_shm_cache+0xa8/0x108optee_shutdown+0x28/0x38platform_shutdown+0x28/0x40device_shutdown+0x144/0x2b0kernel_power_off+0x3c/0x80hibernate+0x35c/0x388state_store+0x64/0x80kobj_attr_store+0x14/0x28sysfs_kf_write+0x48/0x60kernfs_fop_write_iter+0x128/0x1c0vfs_write+0x270/0x370ksys_write+0x6c/0x100__arm64_sys_write+0x20/0x30invoke_syscall+0x4c/0x120el0_svc_common.constprop.0+0x44/0xf0do_el0_svc+0x24/0x38el0_svc+0x24/0x88el0t_64_sync_handler+0x134/0x150el0t_64_sync+0x14c/0x15
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Fix memory allocation size for queue_priority_mapFix a critical memory allocation bug in edma_setup_from_hw() wherequeue_priority_map was allocated with insufficient memory. The codedeclared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),but allocated memory using sizeof(s8) instead of the correct size.This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i;The bug manifested as kernel crashes with "Oops - undefined instruction"on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as thememory corruption triggered kernel hardening features on Clang.Change the allocation to use sizeof(*queue_priority_map) whichautomatically gets the correct size for the 2D array structure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix recursive semaphore deadlock in fiemap callsyzbot detected a OCFS2 hang due to a recursive semaphore on aFS_IOC_FIEMAP of the extent list on a specially crafted mmap file.context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41RSP: 0018:ffffc9000403f950 EFLAGS: 00050256RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5f13850fd9RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03bocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (sincev2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read theextent list of this running mmap executable. The user supplied buffer tohold the fiemap information page faults calling ocfs2_page_mkwrite() whichwill take a write lock (since v2.6.27-38-g00dc417fa3e7) of the samesemaphore. This recursive semaphore will hold filesystem locks and causesa hang of the fileystem.The ip_alloc_sem protects the inode extent list and size. Release theread semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlockon the last extent but simplifies the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error pathDuring tests of another unrelated patch I was able to trigger thiserror: Objects remaining on __kmem_cache_shutdown()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_freeThe previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly atremoval") patched a UAF issue caused by the error timer.However, because the error timer kill added in this patch occurs after theendpoint delete, a race condition to UAF still occurs, albeit rarely.Additionally, since kill-cleanup for urb is also missing, freed memory canbe accessed in interrupt context related to urb, which can cause UAF.Therefore, to prevent this, error timer and urb must be killed beforefreeing the heap memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/ksm: fix flag-dropping behavior in ksm_madvisesyzkaller discovered the following crash: (kernel BUG)[ 44.607039] ------------[ cut here ]------------[ 44.607422] kernel BUG at mm/userfaultfd.c:2067![ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460[ 44.617726] Call Trace:[ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0[ 44.620976] __fput+0x3f9/0xb60[ 44.621240] fput_close_sync+0x110/0x210[ 44.622222] __x64_sys_close+0x8f/0x120[ 44.622530] do_syscall_64+0x5b/0x2f0[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 44.623244] RIP: 0033:0x7f365bb3f227Kernel panics because it detects UFFD inconsistency duringuserfaultfd_release_all(). Specifically, a VMA which has a valid pointerto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.The inconsistency is caused in ksm_madvise(): when user calls madvise()with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,it accidentally clears all flags stored in the upper 32 bits ofvma->vm_flags.Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int andint are 32-bit wide. This setup causes the following mishap during the &=~VM_MERGEABLE assignment.VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is thenpromoted to unsigned long before the & operation. This promotion fillsupper 32 bits with leading 0s, as we're doing unsigned conversion (andeven for a signed conversion, this wouldn't help as the leading bit is 0).& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffffinstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clearsthe upper 32-bits of its value.Fix it by changing `VM_MERGEABLE` constant to unsigned long, using theBIT() macro.Note: other VM_* flags are not affected: This only happens to theVM_MERGEABLE flag, as the other VM_* flags are all constants of type intand after ~ operation, they end up with leading 1 and are thus convertedto unsigned long with leading 1s.Note 2:After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this isno longer a kernel BUG, but a WARNING at the same place:[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067but the root-cause (flag-drop) remains the same.[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Let userspace take care of interrupt maskRemove the logic to set interrupt mask by default in uio_hv_genericdriver as the interrupt mask value is supposed to be controlledcompletely by the user space. If the mask bit gets changedby the driver, concurrently with user mode operating on the ring,the mask bit may be set when it is supposed to be clear, and theuser-mode driver will miss an interrupt which will cause a hang.For eg- when the driver sets inbound ring buffer interrupt mask to 1,the host does not interrupt the guest on the UIO VMBus channel.However, setting the mask does not prevent the host from putting amessage in the inbound ring buffer. So let's assume that happens,the host puts a message into the ring buffer but does not interrupt.Subsequently, the user space code in the guest sets the inbound ringbuffer interrupt mask to 0, saying "Hey, I'm ready for interrupts".User space code then calls pread() to wait for an interrupt.Then one of two things happens:* The host never sends another message. So the pread() waits forever.* The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.This could be easily reproduced in hv_fcopy_uio_daemon if we delaysetting interrupt mask to 0.Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,there's a race condition. Once user space empties the inbound ringbuffer, but before user space sets interrupt_mask to 0, the host couldput another message in the ring buffer but it wouldn't interrupt.Then the next pread() would hang.Fix these by removing all instances where interrupt_mask is changed,while keeping the one in set_event() unchanged to enable userspacecontrol the interrupt mask by writing 0/1 to /dev/uioX.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in __pnet_find_base_ndev().syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),which was called during connect(). [0]smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passesdown to pnet_find_base_ndev(), where RTNL is held. Then, UAF happenedat __pnet_find_base_ndev() when the dev is first used.This means dev had already been freed before acquiring RTNL inpnet_find_base_ndev().While dev is going away, dst->dev could be swapped with blackhole_netdev,and the dev's refcnt by dst will be released.We must hold dev's refcnt before calling smc_pnet_find_ism_resource().Also, smc_pnet_find_roce_resource() has the same problem.Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.[0]:BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f47cbf8eba9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000bRBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bacflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pps: fix warning in pps_register_cdev when register device failSimilar to previous commit 2a934fdb01db ("media: v4l2-dev: fix errorhandling in __video_register_device()"), the release hook should be setbefore device_register(). Otherwise, when device_register() return errorand put_device() try to callback the release function, the below warningmay happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),pps_register_cdev() call device_create() to create pps->dev, which willinit dev->release to device_create_release(). Now the comment is outdated,just remove it.Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removedin pps_register_source() to avoid a double free in the failure case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe0e9fae16dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16dRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen hfsplus_uni2asc is called from hfsplus_listxattr,it actually passes in a struct hfsplus_attr_unistr*.The size of the corresponding structure is different from that of hfsplus_unistr,so the previous fix (94458781aee6) is insufficient.The pointer on the unicode buffer is still going beyond the allocated memory.This patch introduces two warpper functions hfsplus_uni2asc_xattr_str andhfsplus_uni2asc_str to process two unicode buffers,struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.When ustrlen value is bigger than the allocated memory size,the ustrlen value is limited to an safe size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->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.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()During mpt3sas_transport_port_remove(), messages were logged withdev_printk() against &mpt3sas_port->port->dev. At this point the SAStransport device may already be partially unregistered or freed, leadingto a crash when accessing its struct device.Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),guaranteed to remain valid until driver removal.[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0[83428.295844] PKRU: 55555554[83428.295846] Call Trace:[83428.295848] [83428.295850] _dev_printk+0x5c/0x80[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas][83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas][83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas][83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas][83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas][83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas][83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas][83428.295957] pci_device_remove+0x3b/0xb0[83428.295962] device_release_driver_internal+0x193/0x200[83428.295968] driver_detach+0x44/0x90[83428.295971] bus_remove_driver+0x69/0xf0[83428.295975] pci_unregister_driver+0x2a/0xb0[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas][83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296000] ? __x64_sys_getdents64+0x9a/0x110[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296009] ? syscall_trace_enter+0xf6/0x1b0[83428.296014] do_syscall_64+0x7b/0x2c0[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pwm: berlin: Fix wrong register in suspend/resumeThe 'enable' register should be BERLIN_PWM_EN rather thanBERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, therewill be cpu exception then kernel panic during suspend/resume.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()Unlike other strings in the ext4 superblock, we rely on tune2fs tomake sure s_mount_opts is NUL terminated. Hardenparse_apply_sb_mount_options() by treating s_mount_opts as a potential__nonstring.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: reject negative file sizes in squashfs_read_inode()Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size.This commit checks for a negative file size and returns EINVAL.[phillip@squashfs.org.uk: only need to check 64 bit quantity]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid potential out-of-bounds in btrfs_encode_fh()The function btrfs_encode_fh() does not properly account for the threecases it handles.Before writing to the file handle (fh), the function only returns to theuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) orBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).However, when a parent exists and the root ID of the parent and theinode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT(10 dwords, 40 bytes).If *max_len is not large enough, this write goes out of bounds becauseBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater thanBTRFS_FID_SIZE_CONNECTABLE originally returned.This results in an 8-byte out-of-bounds write atfid->parent_root_objectid = parent_root_id.A previous attempt to fix this issue was made but was lost.https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/Although this issue does not seem to be easily triggerable, it is apotential memory corruption bug that should be fixed. This patchresolves the issue by ensuring the function returns the appropriate sizefor all three cases and validates that *max_len is large enough beforewriting any data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential overflow of PCM transfer bufferThe PCM stream data in USB-audio driver is transferred over USB URBpacket buffers, and each packet size is determined dynamically. Thepacket sizes are limited by some factors such as wMaxPacketSize USBdescriptor. OTOH, in the current code, the actually used packet sizesare determined only by the rate and the PPS, which may be bigger thanthe size limit above. This results in a buffer overflow, as reportedby syzbot.Basically when the limit is smaller than the calculated packet size,it implies that something is wrong, most likely a weird USBdescriptor. So the best option would be just to return an error atthe parameter setup time before doing any further operations.This patch introduces such a sanity check, and returns -EINVAL whenthe packet size is greater than maxpacksize. The comparison withep->packsize[1] alone should suffice since it's always equal orgreater than ep->packsize[0].
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_baddIn snd_usb_create_streams(), for UAC version 3 devices, the InterfaceAssociation Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If thiscall fails, a fallback routine attempts to obtain the IAD from the nextinterface and sets a BADD profile. However, snd_usb_mixer_controls_badd()assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,without performing a NULL check. This can lead to a NULL pointerdereference when usb_ifnum_to_if() fails to find the interface descriptor.This patch adds a NULL pointer check after calling usb_ifnum_to_if() insnd_usb_mixer_controls_badd() to prevent the dereference.This issue was discovered by syzkaller, which triggered the bug by sendinga crafted USB device descriptor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZEThis data originates from userspace and is used in buffer offsetcalculations which could potentially overflow causing an out-of-boundsaccess.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-boundsAdd bounds checking to prevent writes past framebuffer boundaries whenrendering text near screen edges. Return early if the Y position is off-screenand clip image height to screen boundary. Break from the rendering loop if theX position is off-screen. When clipping image width to fit the screen, updatethe character count to match the clipped width to prevent buffer sizemismatches.Without the character count update, bit_putcs_aligned and bit_putcs_unalignedreceive mismatched parameters where the buffer is allocated for the clippedwidth but cnt reflects the original larger count, causing out-of-bounds writes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix crash while sending Action Frames in standalone AP ModeCurrently, whenever there is a need to transmit an Action frame,the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR tofirmware. The P2P interfaces were available when wpa_supplicant is managingthe wlan interface.However, the P2P interfaces are not created/initialized when only hostapdis managing the wlan interface. And if hostapd receives an ANQP Query REQAction frame even from an un-associated STA, the brcmfmac driver triesto use an uninitialized P2P vif pointer for sending the IOVAR to firmware.This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)Fix this, by always using the vif corresponding to the wdev on which theAction frame Transmission request was initiated by the userspace. This way,even if P2P vif is not available, the IOVAR is sent to firmware on AP vifand the ANQP Query RESP Action frame is transmitted without crashing thedriver.Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()to brcmf_p2p_attach(). Because the former function would not get executedwhen only hostapd is managing wlan interface, and it is not safe to doreinit_completion() later in brcmf_p2p_tx_action_frame(), without any priorinit_completion().And in the brcmf_p2p_tx_action_frame() function, the condition check forP2P Presence response frame is not needed, since the wpa_supplicant isproperly sending the P2P Presense Response frame on the P2P-GO vif insteadof the P2P-Device vif.[Cc stable]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: validate record offset in hfsplus_bmap_allochfsplus_bmap_alloc can trigger a crash if arecord offset or length is larger than node_size[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0[ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183[ 15.265949][ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)[ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 15.266167] Call Trace:[ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70[ 15.266173] print_report+0xd0/0x660[ 15.266181] kasan_report+0xce/0x100[ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0[ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0[ 15.266217] hfsplus_brec_insert+0x870/0xb00[ 15.266222] __hfsplus_ext_write_extent+0x428/0x570[ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910[ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200[ 15.266233] hfsplus_file_extend+0x5a7/0x1000[ 15.266237] hfsplus_get_block+0x12b/0x8c0[ 15.266238] __block_write_begin_int+0x36b/0x12c0[ 15.266251] block_write_begin+0x77/0x110[ 15.266252] cont_write_begin+0x428/0x720[ 15.266259] hfsplus_write_begin+0x51/0x100[ 15.266262] cont_write_begin+0x272/0x720[ 15.266270] hfsplus_write_begin+0x51/0x100[ 15.266274] generic_perform_write+0x321/0x750[ 15.266285] generic_file_write_iter+0xc3/0x310[ 15.266289] __kernel_write_iter+0x2fd/0x800[ 15.266296] dump_user_range+0x2ea/0x910[ 15.266301] elf_core_dump+0x2a94/0x2ed0[ 15.266320] vfs_coredump+0x1d85/0x45e0[ 15.266349] get_signal+0x12e3/0x1990[ 15.266357] arch_do_signal_or_restart+0x89/0x580[ 15.266362] irqentry_exit_to_user_mode+0xab/0x110[ 15.266364] asm_exc_page_fault+0x26/0x30[ 15.266366] RIP: 0033:0x41bd35[ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f[ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283[ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000[ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100[ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000[ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000[ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000[ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this functionfirst retrieves the bitmap from header node and map node using node->pagetogether with the offset and length from hfs_brec_lenoff```len = hfs_brec_lenoff(node, 2, &off16);off = off16;off += node->page_offset;pagep = node->page + (off >> PAGE_SHIFT);data = kmap_local_page(*pagep);```However, if the retrieved offset or length is invalid(i.e. exceedsnode_size), the code may end up accessing pages outside the allocatedrange for this node.This patch adds proper validation of both offset and length before use,preventing out-of-bounds page access. Move is_bnode_offset_valid andcheck_and_correct_requested_length to hfsplus_fs.h, as they may berequired by other functions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencingTheoretically it's an oopsable race, but I don't believe one can manageto hit it on real hardware; might become doable on a KVM, but it stillwon't be easy to attack.Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call ofput_unaligned_be64(), we can put that under ->d_lock and be done with that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixupRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.This can trigger kernel panics on ARM64 when xfrm or other subsystemsaccess the offset due to strict alignment checks.Initialize the MAC header to prevent such crashes.This can trigger kernel panics on ARM when running IPsec over theqmimux0 interface.Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: multiq3: sanitize config options in multiq3_attach()Syzbot identified an issue [1] in multiq3_attach() that induces atask timeout due to open() or COMEDI_DEVCONFIG ioctl operations,specifically, in the case of multiq3 driver.This problem arose when syzkaller managed to craft weird configurationoptions used to specify the number of channels in encoder subdevice.If a particularly great number is passed to s->n_chan inmultiq3_attach() via it->options[2], then multiple calls tomultiq3_encoder_reset() at the end of driver-specific attach() methodwill be running for minutes, thus blocking tasks and affected devicesas well.While this issue is most likely not too dangerous for real-lifedevices, it still makes sense to sanitize configuration inputs. Enablea sensible limit on the number of encoder chips (4 chips max, eachwith 2 channels) to stop this behaviour from manifesting.[1] Syzbot crash:INFO: task syz.2.19:6067 blocked for more than 143 seconds....Call Trace: context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call pathsThis patch addresses a race condition caused by unsynchronizedexecution of multiple call paths invoking `dwc3_remove_requests()`,leading to premature freeing of USB requests and subsequent crashes.Three distinct execution paths interact with `dwc3_remove_requests()`:Path 1:Triggered via `dwc3_gadget_reset_interrupt()` during USB resethandling. The call stack includes:- `dwc3_ep0_reset_state()`- `dwc3_ep0_stall_and_restart()`- `dwc3_ep0_out_start()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 2:Also initiated from `dwc3_gadget_reset_interrupt()`, but through`dwc3_stop_active_transfers()`. The call stack includes:- `dwc3_stop_active_transfers()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 3:Occurs independently during `adb root` execution, which triggersUSB function unbind and bind operations. The sequence includes:- `gserial_disconnect()`- `usb_ep_disable()`- `dwc3_gadget_ep_disable()`- `dwc3_remove_requests()` with `-ESHUTDOWN` statusPath 3 operates asynchronously and lacks synchronization with Paths1 and 2. When Path 3 completes, it disables endpoints and frees 'out'requests. If Paths 1 or 2 are still processing these requests,accessing freed memory leads to a crash due to use-after-free conditions.To fix this added check for request completion and skip processingif already completed and added the request status for ep0 while queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: intel: punit_ipc: fix memory corruptionThis passes the address of the pointer "&punit_ipcdev" when the intentwas to pass the pointer itself "punit_ipcdev" (without the ampersand).This means that the: complete(&ipcdev->cmd_complete);in intel_punit_ioc() will write to a wrong memory address corrupting it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sock: Prevent race in socket write iter and sock bindThere is a potential race condition between sock bind and socket writeiter. bind may free the same cmd via mgmt_pending before write iter sendsthe cmd, just as syzbot reported in UAF[1].Here we use hci_dev_lock to synchronize the two, thereby avoiding theUAF mentioned in [1].[1]syzbot reported:BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316Read of size 8 at addr ffff888077164818 by task syz.0.17/5989Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Prevents free active keventThe root cause of this issue are:1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);put the kevent work in global workqueue. However, the kevent has not yetbeen scheduled when the usbnet device is unregistered. Therefore, executingfree_netdev() results in the "free active object (kevent)" error reportedhere.2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),if the usbnet device is up, ndo_stop() is executed to cancel the kevent.However, because the device is not up, ndo_stop() is not executed.The solution to this problem is to cancel the kevent before executingfree_netdev().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: bmc150: Fix irq assumption regressionThe code in bmc150-accel-core.c unconditionally callsbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,such as on the runtime PM resume path giving a kernelsplat like this if the device has no interrupts:Unable to handle kernel NULL pointer dereference at virtual address 00000001 when readPC is at bmc150_accel_set_interrupt+0x98/0x194LR is at __pm_runtime_resume+0x5c/0x64(...)Call trace:bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc__iio_update_buffers from enable_store+0x84/0xc8enable_store from kernfs_fop_write_iter+0x154/0x1b4This bug seems to have been in the driver since the beginning,but it only manifests recently, I do not know why.Store the IRQ number in the state struct, as this is a commonpattern in other drivers, then use this to determine if we haveIRQ support or not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexregulator_supply_alias_list was accessed without any locking inregulator_supply_alias(), regulator_register_supply_alias(), andregulator_unregister_supply_alias(). Concurrent registration,unregistration and lookups can race, leading to:1 use-after-free if an alias entry is removed while being read,2 duplicate entries when two threads register the same alias,3 inconsistent alias mappings observed by consumers.Protect all traversals, insertions and deletions onregulator_supply_alias_list with the existing regulator_list_mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()The rtl8187_rx_cb() calculates the rx descriptor header addressby subtracting its size from the skb tail pointer.However, it does not validate if the received packet(skb->len from urb->actual_length) is large enough to contain thisheader.If a truncated packet is received, this will lead to a bufferunderflow, reading memory before the start of the skb data area,and causing a kernel panic.Add length checks for both rtl8187 and rtl8187b descriptor headersbefore attempting to access them, dropping the packet cleanly if thecheck fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_idUse check_add_overflow() to guard against potential integer overflowswhen adding the binary blob lengths and the size of an asymmetric_key_idstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents apossible buffer overflow when copying data from potentially maliciousX.509 certificate fields that can be arbitrarily large, such as ASN.1INTEGER serial numbers, issuer names, etc.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ima: Handle error code returned by ima_filter_rule_match()In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due tothe rule being NULL, the function incorrectly skips the 'if (!rc)' checkand sets 'result = true'. The LSM rule is considered a match, causingextra files to be measured by IMA.This issue can be reproduced in the following scenario:After unloading the SELinux policy module via 'semodule -d', if an IMAmeasurement is triggered before ima_lsm_rules is updated,in ima_match_rules(), the first call to ima_filter_rule_match() returns-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. Inima_lsm_copy_rule(), since the SELinux module has been removed, the rulebecomes NULL, and the second call to ima_filter_rule_match() returns-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that errorcodes like -ENOENT do not bypass the check and accidentally result in asuccessful match.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vgem-fence: Fix potential deadlock on releaseA timer that expires a vgem fence automatically in 10 seconds is nowreleased with timer_delete_sync() from fence->ops.release() called on lastdma_fence_put(). In some scenarios, it can run in IRQ context, which isnot safe unless TIMER_IRQSAFE is used. One potentially risky scenario wasdemonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, whileworking on new IGT subtests syncobj_timeline@stress-* as user spacereplacements of some problematic test cases of a dma-fence-chain selftest[1].[117.004338] ================================[117.004340] WARNING: inconsistent lock state[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U[117.004346] --------------------------------[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190[117.004361] {HARDIRQ-ON-W} state was registered at:[117.004363] lock_acquire+0xc4/0x2e0[117.004366] call_timer_fn+0x80/0x2a0[117.004368] __run_timers+0x231/0x310[117.004370] run_timer_softirq+0x76/0xe0[117.004372] handle_softirqs+0xd4/0x4d0[117.004375] __irq_exit_rcu+0x13f/0x160[117.004377] irq_exit_rcu+0xe/0x20[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20[117.004385] cpuidle_enter_state+0x12b/0x8a0[117.004388] cpuidle_enter+0x2e/0x50[117.004393] call_cpuidle+0x22/0x60[117.004395] do_idle+0x1fd/0x260[117.004398] cpu_startup_entry+0x29/0x30[117.004401] start_secondary+0x12d/0x160[117.004404] common_startup_64+0x13e/0x141[117.004407] irq event stamp: 2282669[117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80[117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0[117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18[117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160[117.004426]other info that might help us debug this:[117.004429] Possible unsafe locking scenario:[117.004432] CPU0[117.004433] ----[117.004434] lock((&fence->timer));[117.004436] [117.004438] lock((&fence->timer));[117.004440] *** DEADLOCK ***[117.004443] 1 lock held by swapper/0/0:[117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0[117.004450]stack backtrace:[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023[117.004456] Call Trace:[117.004456] [117.004457] dump_stack_lvl+0x91/0xf0[117.004460] dump_stack+0x10/0x20[117.004461] print_usage_bug.part.0+0x260/0x360[117.004463] mark_lock+0x76e/0x9c0[117.004465] ? register_lock_class+0x48/0x4a0[117.004467] __lock_acquire+0xbc3/0x2860[117.004469] lock_acquire+0xc4/0x2e0[117.004470] ? __timer_delete_sync+0x4b/0x190[117.004472] ? __timer_delete_sync+0x4b/0x190[117.004473] __timer_delete_sync+0x68/0x190[117.004474] ? __timer_delete_sync+0x4b/0x190[117.004475] timer_delete_sync+0x10/0x20[117.004476] vgem_fence_release+0x19/0x30 [vgem][117.004478] dma_fence_release+0xc1/0x3b0[117.004480] ? dma_fence_release+0xa1/0x3b0[117.004481] dma_fence_chain_release+0xe7/0x130[117.004483] dma_fence_release+0xc1/0x3b0[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80[117.004485] dma_fence_chain_irq_work+0x59/0x80[117.004487] irq_work_single+0x75/0xa0[117.004490] irq_work_r---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix kernel BUG in ocfs2_find_victim_chainsyzbot reported a kernel BUG in ocfs2_find_victim_chain() because the`cl_next_free_rec` field of the allocation chain list (next free slot inthe chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)condition in ocfs2_find_victim_chain() and panicking the kernel.To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),just before calling ocfs2_find_victim_chain(), the code block in it beingexecuted when either of the following conditions is true:1. `cl_next_free_rec` is equal to 0, indicating that there are no freechains in the allocation chain list2. `cl_next_free_rec` is greater than `cl_count` (the total number ofchains in the allocation chain list)Either of them being true is indicative of the fact that there are nochains left for usage.This is addressed using ocfs2_error(), which printsthe error log for debugging purposes, rather than panicking the kernel.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-mixer: us16x08: validate meter packet indicesget_meter_levels_from_urb() parses the 64-byte meter packets sent bythe device and fills the per-channel arrays meter_level[],comp_level[] and master_level[] in struct snd_us16x08_meter_store.Currently the function derives the channel index directly from themeter packet (MUB2(meter_urb, s) - 1) and uses it to index thosearrays without validating the range. If the packet contains anegative or out-of-range channel number, the driver may write pastthe end of these arrays.Introduce a local channel variable and validate it before updating thearrays. We reject negative indices, limit meter_level[] andcomp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]updates with ARRAY_SIZE(master_level).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix memory leak in nr_sendmsg()syzbot reported a memory leak [1].When function sock_alloc_send_skb() return NULL in nr_output(), theoriginal skb is not freed, which was allocated in nr_sendmsg(). Fix thisby freeing it before return.[1]BUG: memory leakunreferenced object 0xffff888129f35500 (size 240): comm "syz.0.17", pid 6119, jiffies 4294944652 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(.... backtrace (crc 1456a3e4): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4983 [inline] slab_alloc_node mm/slub.c:5288 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671 sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965 sock_alloc_send_skb include/net/sock.h:1859 [inline] nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x293/0x2a0 net/socket.c:1195 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0x143/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating zero-sized extent in extent cacheAs syzbot reported:F2FS-fs (loop0): __update_extent_tree_range: extent len is zero, type: 0, extent [0, 0, 0], age [0, 0]------------[ cut here ]------------kernel BUG at fs/f2fs/extent_cache.c:678!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678Call Trace: f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085 f2fs_do_zero_range fs/f2fs/file.c:1657 [inline] f2fs_zero_range+0x10c1/0x1580 fs/f2fs/file.c:1737 f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030 vfs_fallocate+0x669/0x7e0 fs/open.c:342 ioctl_preallocate fs/ioctl.c:289 [inline] file_ioctl+0x611/0x780 fs/ioctl.c:-1 do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576 __do_sys_ioctl fs/ioctl.c:595 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f07bc58eec9In error path of f2fs_zero_range(), it may add a zero-sized extentinto extent cache, it should be avoided.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()rlen value is a user-controlled value, but dtv5100_i2c_msg() does notcheck the size of the rlen value. Therefore, if it is set to a valuelarger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.Therefore, we need to add proper range checking to prevent this vuln.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: invalidate dentry cache on failed whiteout creationF2FS can mount filesystems with corrupted directory depth values thatget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUToperations are performed on such directories, f2fs_rename performsdirectory modifications (updating target entry and deleting sourceentry) before attempting to add the whiteout entry via f2fs_add_link.If f2fs_add_link fails due to the corrupted directory structure, thefunction returns an error to VFS, but the partial directorymodifications have already been committed to disk. VFS assumes theentire rename operation failed and does not update the dentry cache,leaving stale mappings.In the error path, VFS does not call d_move() to update the dentrycache. This results in new_dentry still pointing to the old inode(new_inode) which has already had its i_nlink decremented to zero.The stale cache causes subsequent operations to incorrectly referencethe freed inode.This causes subsequent operations to use cached dentry information thatno longer matches the on-disk state. When a second rename targets thesame entry, VFS attempts to decrement i_nlink on the stale inode, whichmay already have i_nlink=0, triggering a WARNING in drop_nlink().Example sequence:1. First rename (RENAME_WHITEOUT): file2 -> file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 -> inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)2. Second rename: file3 -> file1 - VFS uses stale cache: file1 -> inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()Fix this by explicitly invalidating old_dentry and new_dentry whenf2fs_add_link fails during whiteout creation. This forces VFS torefresh from disk on subsequent operations, ensuring cache consistencyeven when the rename partially succeeds.Reproducer:1. Mount F2FS image with corrupted i_current_depth2. renameat2(file2, file1, RENAME_WHITEOUT)3. renameat2(file3, file1, 0)4. System triggers WARNING in drop_nlink()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_writeA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()due to lock ordering inversion between device_lock and rfkill_global_mutex.The problematic lock order is:Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lockThread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutexThis creates a classic ABBA deadlock scenario.Fix this by moving rfkill_unregister() and rfkill_destroy() outside thedevice_lock critical section. Store the rfkill pointer in a local variablebefore releasing the lock, then call rfkill_unregister() after releasingdevice_lock.This change is safe because rfkill_fop_write() holds rfkill_global_mutexwhile calling the rfkill callbacks, and rfkill_unregister() also acquiresrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() willwait for any ongoing callback to complete before proceeding, anddevice_del() is only called after rfkill_unregister() returns, preventingany use-after-free.The similar lock ordering in nfc_register_device() (device_lock ->rfkill_global_mutex via rfkill_register) is safe because duringregistration the device is not yet in rfkill_list, so no concurrentrfkill operations can occur on this device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: revert use of devm_kzalloc in btusbThis reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc inbtusb.c file").In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. Thisties the lifetime of all the btusb data to the binding of a driver toone interface, INTF. In a driver that binds to other interfaces, ISOCand DIAG, this is an accident waiting to happen.The issue is revealed in btusb_disconnect(), where callingusb_driver_release_interface(&btusb_driver, data->intf) will have devmfree the data that is also being used by the other interfaces of thedriver that may not be released yet.To fix this, revert the use of devm and go back to freeing memoryexplicitly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Avoid NULL pointer deref for evicted BOsIt is possible for a BO to exist that is not currently associated with aresource, e.g. because it has been evicted.When devcoredump tries to read the contents of all BOs for dumping, we needto expect this as well -- in this case, ENODATA is recorded instead of thebuffer contents.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Do not use req->iv after crypto_aead_encryptAs soon as crypto_aead_encrypt is called, the underlying requestmay be freed by an asynchronous completion. Thus dereferencingreq->iv after it returns is invalid.Instead of checking req->iv against info, create a new variableunaligned_info and use it for that purpose instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()It's possible for cp_read() and hdmi_read() to return -EIO. Thosevalues are further used as indexes for accessing arrays.Fix that by checking return values where it's needed.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: When extracting a tar archive pip may not check symbolic links point into the extraction directory if the tarfile module doesn't implement PEP 706.Note that upgrading pip to a "fixed" version for this vulnerability doesn't fix all known vulnerabilities that are remediated by using a Python version that implements PEP 706.Note that this is a vulnerability in pip's fallback implementation of tar extraction for Python versions that don't implement PEP 706and therefore are not secure to all vulnerabilities in the Python 'tarfile' module. If you're using a Python version that implements PEP 706then pip doesn't use the "vulnerable" fallback code.Mitigations include upgrading to a version of pip that includes the fix, upgrading to a Python version that implements PEP 706 (Python >=3.9.17, >=3.10.12, >=3.11.4, or >=3.12),applying the linked patch, or inspecting source distributions (sdists) before installation as is already a best-practice.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat > 0-0 (version in image is 2.1.0-21.28.1).
-
Description: Directory traversal vulnerability in the (1) extract and (2) extractall functions in the tarfile module in Python allows user-assisted remote attackers to overwrite arbitrary files via a .. (dot dot) sequence in filenames in a TAR archive, a related issue to CVE-2001-1267.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.116.1).
-
Description: An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \r\n (specifically in the query string after a ? character) followed by an HTTP header or a Redis command. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10, v3.5.10rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.9, v3.6.9rc1; v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification 1.0B through 5.2 may permit an unauthenticated nearby device to spoof the BD_ADDR of the peer device to complete pairing without knowledge of the PIN.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.189.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()The voice allocator sometimes begins allocating from near the end of thearray and then wraps around, however snd_emu10k1_pcm_channel_alloc()accesses the newly allocated voices as if it never wrapped around.This results in out of bounds access if the first voice has a high enoughindex so that first_voice + requested_voice_count > NUM_G (64).The more voices are requested, the more likely it is for this to occur.This was initially discovered using PipeWire, however it can be reproducedby calling aplay multiple times with 16 channels:aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zeroUBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40index 65 is out of range for type 'snd_emu10k1_voice [64]'CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010Call Trace:dump_stack_lvl+0x49/0x63dump_stack+0x10/0x16ubsan_epilogue+0x9/0x3f__ubsan_handle_out_of_bounds.cold+0x44/0x49snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]snd_pcm_hw_params+0x29f/0x600 [snd_pcm]snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]? exit_to_user_mode_prepare+0x35/0x170? do_syscall_64+0x69/0x90? syscall_exit_to_user_mode+0x26/0x50? do_syscall_64+0x69/0x90? exit_to_user_mode_prepare+0x35/0x170snd_pcm_ioctl+0x27/0x40 [snd_pcm]__x64_sys_ioctl+0x95/0xd0do_syscall_64+0x5c/0x90? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-Jinja2 > 0-0 (version in image is 2.8-22.11.1).
-
Description: A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.15.1 (version in image is 0.8.7-3.9.1).
-
Description: An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers is calculated and truncated into a 32-bit integer. A pointer to partially controlled data can then be written out of bounds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsqlite3-0 > 0-0 (version in image is 3.39.3-9.26.1).
-
Description: Python Software Foundation Python (CPython) version 2.7 contains a CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in shutil module (make_archive function) that can result in Denial of service, Information gain via injection of arbitrary files on the system or entire drive. This attack appear to be exploitable via Passage of unfiltered user input to the function. This vulnerability appears to have been fixed in after commit add531a1e55b0a739b0f42582f1c9747e5649ace.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The _bfd_XX_bfd_copy_private_bfd_data_common function in peXXigen.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, processes a negative Data Directory size with an unbounded loop that increases the value of (external_IMAGE_DEBUG_DIRECTORY) *edd so that the address exceeds its own memory region, resulting in an out-of-bounds memory write, as demonstrated by objcopy copying private info with _bfd_pex64_bfd_copy_private_bfd_data_common in pex64igen.c.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: It was found that the GnuTLS implementation of HMAC-SHA-256 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data using crafted packets.
Packages affected:
- libgnutls30 > 0-0 (version in image is 3.4.17-8.14.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of "Just in Time" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets.
Packages affected:
- libgnutls30 > 0-0 (version in image is 3.4.17-8.14.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
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:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-ply > 0-0 (version in image is 3.4-3.3.1).
-
Description: In GNU Binutils 2.30, there's an integer overflow in the function load_specific_debug_section() in objdump.c, which results in `malloc()` with 0 size. A crafted ELF file allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The bfd_get_debug_link_info_1 function in opncls.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, has an unchecked strnlen operation. Remote attackers could leverage this vulnerability to cause a denial of service (segmentation fault) via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A flaw was found in libssh versions before 0.8.9 and before 0.9.4 in the way it handled AES-CTR (or DES ciphers if enabled) ciphers. The server or client could crash when the connection hasn't been fully initialized and the system tries to cleanup the ciphers when closing the connection. The biggest threat from this vulnerability is system availability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: An uncontrolled resource consumption (memory leak) flaw was found in the ZeroMQ client in versions before 4.3.3 in src/pipe.cpp. This issue causes a client that connects to multiple malicious or compromised servers to crash. The highest threat from this vulnerability is to system availability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libzmq3 > 0-0 (version in image is 4.0.4-15.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix masking negation logic upon negative dst registerThe negation logic for the case where the off_reg is sitting in thedst register is not correct given then we cannot just invert the addto a sub or vice versa. As a fix, perform the final bitwise and-opunconditionally into AX from the off_reg, then move the pointer fromthe src to dst and finally use AX as the source for the originalpointer arithmetic operation such that the inversion yields a correctresult. The single non-AX mov in between is possible given constantblinding is retaining it as it's not an immediate based operation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nftables: avoid overflows in nft_hash_buckets()Number of buckets being stored in 32bit variables, we have toensure that no overflows occur in nft_hash_buckets()syzbot injected a size == 0x40000000 and reported:UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13shift exponent 64 is too large for 64-bit type 'long unsigned int'CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Clear all QP fields if creation failedrxe_qp_do_cleanup() relies on valid pointer values in QP for the properlycreated ones, but in case rxe_qp_from_init() failed it was filled withgarbage and caused tot the following error. refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805 execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline] rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline] create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717 enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm btree remove: assign new_root only when removal succeedsremove_raw() in dm_btree_remove() may fail due to IO read error(e.g. read the content of origin block fails during shadowing),and the value of shadow_spine::root is uninitialized, butthe uninitialized value is still assign to new_root in theend of dm_btree_remove().For dm-thin, the value of pmd->details_root or pmd->root will becomean uninitialized value, so if trying to read details_info tree againout-of-bound memory may occur as showed below: general protection fault, probably for non-canonical address 0x3fdcb14c8d7520 CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6 Hardware name: QEMU Standard PC RIP: 0010:metadata_ll_load_ie+0x14/0x30 Call Trace: sm_metadata_count_is_more_than_one+0xb9/0xe0 dm_tm_shadow_block+0x52/0x1c0 shadow_step+0x59/0xf0 remove_raw+0xb2/0x170 dm_btree_remove+0xf4/0x1c0 dm_pool_delete_thin_device+0xc3/0x140 pool_message+0x218/0x2b0 target_message+0x251/0x290 ctl_ioctl+0x1c4/0x4d0 dm_ctl_ioctl+0xe/0x20 __x64_sys_ioctl+0x7b/0xb0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xaeFixing it by only assign new_root when removal succeeds
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:moxart: fix potential use-after-free on remove pathIt was reported that the mmc host structure could be accessed after itwas freed in moxart_remove(), so fix this by saving the base register ofthe device and using it instead of the pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of: fdt: fix off-by-one error in unflatten_dt_nodes()Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")forgot to fix up the depth check in the loop body in unflatten_dt_nodes()which makes it possible to overflow the nps[] buffer...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: fix possible use-after-free in transport error_recovery workWhile nvme_rdma_submit_async_event_work is checking the ctrl and queuestate before preparing the AER command and scheduling io_work, in orderto fully prevent a race where this check is not reliable the errorrecovery work must flush async_event_work before continuing to destroythe admin queue after setting the ctrl state to RESETTING such thatthere is no race .submit_async_event and the error recovery handleritself changing the ctrl state.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: ensure we call ipv6_mc_down() at most onceThere are two reasons for addrconf_notify() to be called with NETDEV_DOWN:either the network device is actually going down, or IPv6 was disabledon the interface.If either of them stays down while the other is toggled, we repeatedlycall the code for NETDEV_DOWN, including ipv6_mc_down(), while nevercalling the corresponding ipv6_mc_up() in between. This will cause anew entry in idev->mc_tomb to be allocated for each multicast groupthe interface is subscribed to, which in turn leaks one struct ifmcaddr6per nontrivial multicast group the interface is subscribed to.The following reproducer will leak at least $n objects:ip addr add ff2e::4242/32 dev eth0 autojoinsysctl -w net.ipv6.conf.eth0.disable_ipv6=1for i in $(seq 1 $n); do ip link set up eth0; ip link set down eth0doneJoining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting thesysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)can also be used to create a nontrivial idev->mc_list, which will theleak objects with the right up-down-sequence.Based on both sources for NETDEV_DOWN events the interface IPv6 stateshould be considered: - not ready if the network interface is not ready OR IPv6 is disabled for it - ready if the network interface is ready AND IPv6 is enabled for itThe functions ipv6_mc_up() and ipv6_down() should only be run when thisstate changes.Implement this by remembering when the IPv6 state is ready, and onlyrun ipv6_mc_down() if it actually changed from ready to not ready.The other direction (not ready -> ready) already works correctly, as: - the interface notification triggered codepath for NETDEV_UP / NETDEV_CHANGE returns early if ipv6 is disabled, and - the disable_ipv6=0 triggered codepath skips fully initializing the interface as long as addrconf_link_ready(dev) returns false - calling ipv6_mc_up() repeatedly does not leak anything
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: fix shift-out-of-bounds in hid_report_raw_eventSyzbot reported shift-out-of-bounds in hid_report_raw_event.microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >32! (swapper/0)======================================================================UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20shift exponent 127 is too large for 32-bit type 'int'CPU: 0 PID: 0 Comm: swapper/0 Not tainted6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0Hardware name: Google Compute Engine/Google Compute Engine, BIOSGoogle 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107======================================================================If the size of the integer (unsigned n) is bigger than 32 in snto32(),shift exponent will be too large for 32-bit type 'int', resulting in ashift-out-of-bounds bug.Fix this by adding a check on the size of the integer (unsigned n) insnto32(). To add support for n greater than 32 bits, set n to 32, if nis greater than 32.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Prevent RSB underflow before vmenterOn VMX, there are some balanced returns between the time the guest'sSPEC_CTRL value is written, and the vmenter.Balanced returns (matched by a preceding call) are usually ok, but it'sat least theoretically possible an NMI with a deep call stack couldempty the RSB before one of the returns.For maximum paranoia, don't allow *any* returns (balanced or otherwise)between the SPEC_CTRL write and the vmenter. [ bp: Fix 32-bit build. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: fix misuse of put_device() in mISDN_register_device()We should not release reference by put_device() before calling device_initialize().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Remove device endpoints from bandwidth list when freeing the deviceEndpoints are normally deleted from the bandwidth list when they aredropped, before the virt device is freed.If xHC host is dying or being removed then the endpoints aren't droppedcleanly due to functions returning early to avoid interacting with anon-accessible host controller.So check and delete endpoints that are still on the bandwidth list whenfreeing the virt device.Solves a list_del corruption kernel crash when unbinding xhci-pci,caused by xhci_mem_cleanup() when it later tried to delete already freedendpoints from the bandwidth list.This only affects hosts that use software bandwidth checking, whichcurrenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.119.1 (version in image is 3.4.10-25.116.1).
-
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.11-11.37.1 (version in image is 1.2.11-11.34.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers/amd/pm: fix a use-after-free in kv_parse_power_tableWhen ps allocated by kzalloc equals to NULL, kv_parse_power_tablefrees adev->pm.dpm.ps that allocated before. However, after the controlflow goes through the following call chains:kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_finiThe adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after itsfirst free in kv_parse_power_table and causes a use-after-free bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in diAllocCurrently there is not check against the agno of the iag whileallocating new inodes to avoid fragmentation problem. Added the checkwhich is required.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: fix shift-out-of-bounds in exponential backoffThe ENA adapters on our instances occasionally reset. Once recentlylogged a UBSAN failure to console in the process: UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue: ena ena_fw_reset_device [ena] Call Trace: dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e ? __const_udelay+0x43/0x50 ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena] wait_for_reset_state+0x54/0xa0 [ena] ena_com_dev_reset+0xc8/0x110 [ena] ena_down+0x3fe/0x480 [ena] ena_destroy_device+0xeb/0xf0 [ena] ena_fw_reset_device+0x30/0x50 [ena] process_one_work+0x22b/0x3d0 worker_thread+0x4d/0x3f0 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Apparently, the reset delays are getting so large they can trigger aUBSAN panic.Looking at the code, the current timeout is capped at 5000us. Using abase value of 100us, the current code will overflow after (1<<29). Evenat values before 32, this function wraps around, perhapsunintentionally.Cap the value of the exponent used for this backoff at (1<<16) which islarger than currently necessary, but large enough to support biggervalues in the future.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix WARNING in mb_find_extentSyzbot found the following issue:EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!EXT4-fs (loop0): orphan cleanup on readonly fs------------[ cut here ]------------WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30Modules linked in:CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2ccFS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307 ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735 ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605 ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286 ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651 ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864 ext4_bread+0x2a/0x170 fs/ext4/inode.c:920 ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105 write_blk fs/quota/quota_tree.c:64 [inline] get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130 do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 dq_insert_tree fs/quota/quota_tree.c:401 [inline] qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420 v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358 dquot_acquire+0x348/0x670 fs/quota/dquot.c:444 ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740 dqget+0x999/0xdc0 fs/quota/dquot.c:914 __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492 ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [inline] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdAdd some debug information:mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAcctually, blocks per group is 64, but block bitmap indicate at least has128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block'sbitmap if set.To resolve above issue, add check like fsck "Padding at end of block bitmap isnot set".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix possible data races in gfs2_show_options()Some fields such as gt_logd_secs of the struct gfs2_tune are accessedwithout holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);And thus can cause data races when gfs2_show_options() and other functionssuch as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit;To fix these possible data races, the lock sdp->sd_tune.gt_spin isacquired before accessing the fields of gfs2_tune and released after theseaccesses.Further changes by Andreas:- Don't hold the spin lock over the seq_printf operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix out of bounds access in DCCP error handlerThere was a previous attempt to fix an out-of-bounds access in the DCCPerror handlers, but that fix assumed that the error handlers only wantto access the first 8 bytes of the DCCP header. Actually, they also lookat the DCCP sequence number, which is stored beyond 8 bytes, so anexplicit pskb_may_pull() is required.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Issue summary: Generating excessively long X9.42 DH keys or checkingexcessively long X9.42 DH keys or parameters may be very slow.Impact summary: Applications that use the functions DH_generate_key() togenerate an X9.42 DH key may experience long delays. Likewise, applicationsthat use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()to check an X9.42 DH key or X9.42 DH parameters may experience long delays.Where the key or parameters that are being checked have been obtained froman untrusted source this may lead to a Denial of Service.While DH_check() performs all the necessary checks (as of CVE-2023-3817),DH_check_pub_key() doesn't make any of these checks, and is thereforevulnerable for excessively large P and Q parameters.Likewise, while DH_generate_key() performs a check for an excessively largeP, it doesn't check for an excessively large Q.An application that calls DH_generate_key() or DH_check_pub_key() andsupplies a key or parameters obtained from an untrusted source could bevulnerable to a Denial of Service attack.DH_generate_key() and DH_check_pub_key() are also called by a number ofother OpenSSL functions. An application calling any of those otherfunctions may similarly be affected. The other functions affected by thisare DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().Also vulnerable are the OpenSSL pkey command line application when using the"-pubcheck" option, as well as the OpenSSL genpkey command line application.The OpenSSL SSL/TLS implementation is not affected by this issue.The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
Packages affected:
- libopenssl1_0_0 < 1.0.2p-3.87.1 (version in image is 1.0.2p-3.84.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A flaw was found in the libssh implements abstract layer for message digest (MD) operations implemented by different supported crypto backends. The return values from these were not properly checked, which could cause low-memory situations failures, NULL dereferences, crashes, or usage of the uninitialized memory as an input for the KDF. In this case, non-matching keys will result in decryption/integrity failures, terminating the connection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- rsync < 3.1.3-3.22.1 (version in image is 3.1.3-3.14.1).
-
Description: A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libgnutls30 > 0-0 (version in image is 3.4.17-8.14.1).
-
Description: Allows modifying some file metadata (e.g. last modified) with filter="data" or file permissions (chmod) with filter="tar" of files outside the extraction directory.You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_4m1_0 < 3.4.10-25.169.1 (version in image is 3.4.10-25.116.1).
-
Description: NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.This issue affects Linux kernel: v2.6.12-rc2.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: nv04: Fix out of bounds accessWhen Output Resource (dcb->or) value is assigned infabricate_dcb_output(), there may be out of bounds access todac_users array in case dcb->or is zero because ffs(dcb->or) isused as index there.The 'or' argument of fabricate_dcb_output() must be interpreted as anumber of bit to set, not value.Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_rx_worksyzbot reported the following uninit-value access issue [1]nci_rx_work() parses received packet from ndev->rx_q. It should bevalidated header size, payload size and total packet size beforeprocessing the packet. If an invalid packet is detected, it should besilently discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Add tx check to prevent skb leakBelow is a summary of how the driver stores a reference to an skb duringtransmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++;Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=
, skb=, skb=null, skb=null]The driver has checks to ensure that free_map[consumer_index] pointed toa valid index but there was no check to ensure that this index pointedto an unused/null skb address. So, if, by some chance, our free_map andtx_buff lists become out of sync then we were previously risking anskb memory leak. This could then cause tcp congestion control to stopsending packets, eventually leading to ETIMEDOUT.Therefore, add a conditional to ensure that the skb address is null. Ifnot then warn the user (because this is still a bug that should bepatched) and free the old pointer to prevent memleak/tcp problems.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: pca953x: fix pca953x_irq_bus_sync_unlock raceEnsure that `i2c_lock' is held when setting interrupt latch and mask inpca953x_irq_bus_sync_unlock() in order to avoid races.The other (non-probe) call site pca953x_gpio_set_multiple() ensures thelock is held before calling pca953x_write_regs().The problem occurred when a request raced against irq_bus_sync_unlock()approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:protect the fetch of ->fd[fd] in do_dup2() from mispredictionsboth callers have verified that fd is not greater than ->max_fds;however, misprediction might end up with tofree = fdt->fd[fd];being speculatively executed. That's wrong for the same reasonswhy it's wrong in close_fd()/file_close_fd_locked(); the samesolution applies - array_index_nospec(fd, fdt->max_fds) could differfrom fd only in case of speculative execution on mispredicted path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.231.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid OOB when system.data xattr changes underneath the filesystemWhen looking up for an entry in an inlined directory, if e_value_offs ischanged underneath the filesystem by some change in the block device, itwill lead to an out-of-bounds access that KASAN detects as an UAF.EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.loop0: detected capacity change from 2048 to 2047==================================================================BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f3e73ced469Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010aRAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27cR13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode withext4_get_inode_loc will lead to a check of the validity of the xattrs,avoiding this problem.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.18.1).
-
Description: A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libavahi-client3 > 0-0 (version in image is 0.6.32-32.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - add error check in the ahash_hmac_init functionThe ahash_init functions may return fails. The ahash_hmac_init shouldnot return ok when ahash_init returns error. For an example, ahash_initwill return -ENOMEM when allocation memory is error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix freeing of the HMB descriptor tableThe HMB descriptor table is sized to the maximum number of descriptorsthat could be used for a given device, but __nvme_alloc_host_mem couldbreak out of the loop earlier on memory allocation failure and end upusing less descriptors than planned for, which leads to an incorrectsize passed to dma_free_coherent.In practice this was not showing up because the number of descriptorstends to be low and the dma coherent allocator always allocates andfrees at least a page.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: When curl is asked to use HSTS, the expiry time for a subdomain mightoverwrite a parent domain's cache entry, making it end sooner or later thanotherwise intended.This affects curl using applications that enable HSTS and use URLs with theinsecure `HTTP://` scheme and perform transfers with hosts like`x.example.com` as well as `example.com` where the first host is a subdomainof the second host.(The HSTS cache either needs to have been populated manually or there needs tohave been previous HTTPS accesses done as the cache needs to have entries forthe domains involved to trigger this problem.)When `x.example.com` responds with `Strict-Transport-Security:` headers, thisbug can make the subdomain's expiry timeout *bleed over* and get set for theparent domain `example.com` in curl's HSTS cache.The result of a triggered bug is that HTTP accesses to `example.com` getconverted to HTTPS for a different period of time than what was asked for bythe origin server. If `example.com` for example stops supporting HTTPS at itsexpiry time, curl might then fail to access `http://example.com` until the(wrongly set) timeout expires. This bug can also expire the parent's entry*earlier*, thus making curl inadvertently switch back to insecure HTTP earlierthan otherwise intended.
Packages affected:
- curl > 0-0 (version in image is 8.0.1-11.74.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: When asked to use a `.netrc` file for credentials **and** to follow HTTPredirects, curl could leak the password used for the first host to thefollowed-to host under certain circumstances.This flaw only manifests itself if the netrc file has a `default` entry thatomits both login and password. A rare circumstance.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.105.1 (version in image is 8.0.1-11.74.1).
-
Description: A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl > 0-0 (version in image is 8.0.1-11.74.1).
-
Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl > 0-0 (version in image is 8.0.1-11.74.1).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl > 0-0 (version in image is 8.0.1-11.74.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: cls_flow: validate TCA_FLOW_RSHIFT attributesyzbot found that TCA_FLOW_RSHIFT attribute was not validated.Right shitfing a 32bit integer is undefined for large shift values.UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: ipv6_addrconf addrconf_dad_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix memory accounting leak.Matt Dowling reported a weird UDP memory usage issue.Under normal operation, the UDP memory usage reported in /proc/net/sockstatremains close to zero. However, it occasionally spiked to 524,288 pagesand never dropped. Moreover, the value doubled when the application wasterminated. Finally, it caused intermittent packet drops.We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577The application set INT_MAX to SO_RCVBUF, which triggered an integeroverflow in udp_rmem_release().When a socket is close()d, udp_destruct_common() purges its receivequeue and sums up skb->truesize in the queue. This total is calculatedand stored in a local unsigned integer variable.The total size is then passed to udp_rmem_release() to adjust memoryaccounting. However, because the function takes a signed integerargument, the total size can wrap around, causing an overflow.Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().When the issue occurred, the total in udp_destruct_common() was 2147484480(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and2) sets -2147479552 to amount. 3) reverts the wraparound, so we don'tsee a warning in inet_sock_destruct(). However, udp_memory_allocatedends up doubling at 4).Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves formemory_allocated"), memory usage no longer doubles immediately aftera socket is close()d because __sk_mem_reduce_allocated() caches theamount in udp_memory_per_cpu_fw_alloc. However, the next time a UDPsocket receives a packet, the subtraction takes effect, causing UDPmemory usage to double.This issue makes further memory allocation fail once the socket'ssk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packetdrops.To prevent this issue, let's use unsigned int for the calculation andcall sk_forward_alloc_add() only once for the small delta.Note that first_packet_length() also potentially has the same problem.[0]:from socket import *SO_RCVBUFFORCE = 33INT_MAX = (2 ** 31) - 1s = socket(AF_INET, SOCK_DGRAM)s.bind(('', 0))s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)c = socket(AF_INET, SOCK_DGRAM)c.connect(s.getsockname())data = b'a' * 100while True: c.send(data)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: The attack vector is a potential Denial of Service (DoS). The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: In the CGI gem before 0.4.2 for Ruby, the CGI::Cookie.parse method in the CGI library contains a potential Denial of Service (DoS) vulnerability. The method does not impose any limit on the length of the raw cookie value it processes. This oversight can lead to excessive resource consumption when parsing extremely large cookies.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: In the CGI gem before 0.4.2 for Ruby, a Regular Expression Denial of Service (ReDoS) vulnerability exists in the Util#escapeElement method.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: In the URI gem before 1.0.3 for Ruby, the URI handling methods (URI.join, URI#merge, URI#+) have an inadvertent leakage of authentication credentials because userinfo is retained even after changing the host.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: check that event count does not exceed event buffer lengthThe event count is read from register DWC3_GEVNTCOUNT.There is a check for the count being zero, but not for exceeding theevent buffer length.Check that event count does not exceed event buffer length,avoiding an out-of-bounds access when memcpy'ing the event.Crash log:Unable to handle kernel paging request at virtual address ffffffc0129be000pc : __memcpy+0x114/0x180lr : dwc3_check_event_buf+0xec/0x348x3 : 0000000000000030 x2 : 000000000000dfc4x1 : ffffffc0129be000 x0 : ffffff87aad60080Call trace:__memcpy+0x114/0x180dwc3_interrupt+0x24/0x34
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Abort software beacon handling if disabledA malicious USB device can send a WMI_SWBA_EVENTID event from anath9k_htc-managed device before beaconing has been enabled. This causesa device-by-zero error in the driver, leading to either a crash or anout of bounds read.Prevent this by aborting the handling in ath9k_htc_swba() if beacons arenot enabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: marvell/cesa - Handle zero-length skcipher requestsDo not access random memory for zero-length skcipher requests.Just return 0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in cifs_oplock_breakA race condition can occur in cifs_oplock_break() leading to ause-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAFThe issue occurs when umount has already released its reference to thesuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), thisreleases the last reference, triggering the immediate cleanup of allinodes under RCU. However, cifs_oplock_break() continues to access thecinode after this point, resulting in use-after-free.Fix this by holding an extra reference to the superblock during theentire oplock break operation. This ensures that the superblock andits inodes remain valid until the oplock break completes.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: initialize more fields in sctp_v6_from_sk()syzbot found that sin6_scope_id was not properly initialized,leading to undefined behavior.Clear sin6_scope_id and sin6_flowinfo.BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()The hfsplus_strcasecmp() logic can trigger the issue:[ 117.317703][ T9855] ==================================================================[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855[ 117.319577][ T9855][ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 117.319783][ T9855] Call Trace:[ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319842][ T9855] print_report+0x17e/0x7e0[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319876][ T9855] kasan_report+0x147/0x180[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0[ 117.320055][ T9855] lookup_slow+0x53/0x70[ 117.320065][ T9855] walk_component+0x2f0/0x430[ 117.320073][ T9855] path_lookupat+0x169/0x440[ 117.320081][ T9855] filename_lookup+0x212/0x590[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540[ 117.320112][ T9855] user_path_at+0x3a/0x60[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
-
Description: xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-osconfig-agent > 0-0 (version in image is 20230706.02-1.23.3).
-
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- google-guest-agent > 0-0 (version in image is 20230601.00-1.32.3).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- openssh < 7.2p2-81.34.1 (version in image is 7.2p2-81.4.2).
-
Description: ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- openssh > 0-0 (version in image is 7.2p2-81.4.2).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc > 0-0 (version in image is 2.22-114.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: iscsi: Fix conn use after free during resetsIf we haven't done a unbind target call we can race whereiscsi_conn_teardown wakes up the EH thread and then frees the conn whilethose threads are still accessing the conn ehwait.We can only do one TMF per session so this just moves the TMF fields fromthe conn to the session. We can then rely on theiscsi_session_teardown->iscsi_remove_session->__iscsi_unbind_session callto remove the target and it's devices, and know after that point there isno device or scsi-ml callout trying to access the session.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: fix potential kgd_mem UAFskgd_mem pointers returned by kfd_process_device_translate_handle areonly guaranteed to be valid while p->mutex is held. As soon as the mutexis unlocked, another thread can free the BO.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm rq: fix double free of blk_mq_tag_set in dev remove after table load failsWhen loading a device-mapper table for a request-based mapped device,and the allocation/initialization of the blk_mq_tag_set for the devicefails, a following device remove will cause a double free.E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oopsWhen allocation/initialization of the blk_mq_tag_set fails indm_mq_init_request_queue(), it is uninitialized/freed, but the pointeris not reset to NULL; so when dev_remove() later gets intodm_mq_cleanup_mapped_device() it sees the pointer and tries touninitialize and free it again.Fix this by setting the pointer to NULL in dm_mq_init_request_queue()error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: fix stack overflow in line6_midi_transmitCorrectly calculate available space including the size of the chunkbuffer. This fixes a buffer overflow when multiple MIDI sysexmessages are sent to a PODxt device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: smscufx: Fix several use-after-free bugsSeveral types of UAFs can occur when physically removing a USB device.Adds ufx_ops_destroy() function to .fb_destroy of fb_ops, andin this function, there is kref_put() that finally calls ufx_free().This fix prevents multiple UAFs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries/memhp: Fix access beyond end of drmem arraydlpar_memory_remove_by_index() may access beyond the bounds of thedrmem lmb array when the LMB lookup fails to match an entry with thegiven DRC index. When the search fails, the cursor is left pointing to&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past thelast valid entry in the array. The debug message at the end of thefunction then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr);This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0Log failed lookups with a separate message and dereference thecursor only when it points to a valid entry.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: possible buffer overflowBuffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' ischecked after access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't trust firmware n_channelsIf the firmware sends us a corrupted MCC response withn_channels much larger than the command response can be,we might copy far too much (uninitialized) memory andeven crash if the n_channels is large enough to make itrun out of the one page allocated for the FW response.Fix that by checking the lengths. Doing a < comparisonwould be sufficient, but the firmware should be doingit correctly, so check more strictly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Fix crash due to uninitialized current_vmcsKVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running asa nested hypervisor on top of Hyper-V. When MSR bitmap is updated,evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to markthat the msr bitmap was changed.vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr-> vmx_msr_bitmap_l01_changed which in the end calls this function. Thefunction checks for current_vmcs if it is null but the check isinsufficient because current_vmcs is not initialized. Because of this, thecode might incorrectly write to the structure pointed by current_vmcs valueleft by another task. Preemption is not disabled, the current task can bepreempted and moved to another CPU while current_vmcs is accessed multipletimes from evmcs_touch_msr_bitmap() which leads to crash.The manipulation of MSR bitmaps by callers happens only for vmcs01 so thesolution is to use vmx->vmcs01.vmcs instead of current_vmcs. BUG: kernel NULL pointer dereference, address: 0000000000000338 PGD 4e1775067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI ... RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel] ... Call Trace: vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel] vmx_vcpu_create+0xe6/0x540 [kvm_intel] kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm] kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm] kvm_vm_ioctl+0x53f/0x790 [kvm] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bna: ensure the copied buf is NUL terminatedCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes fromuserspace to that buffer. Later, we use sscanf on this buffer but we don'tensure that the string is terminated inside the buffer, this can lead toOOB read when using sscanf. Fix this issue by using memdup_user_nulinstead of memdup_user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDINGXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang withsmall possibility, the root cause is exactly the same as commitbed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")However, Dan reported another hang after that, and junxiao investigatedthe problem and found out that this is caused by plugged bio can't issuefrom raid5d().Current implementation in raid5d() has a weird dependence:1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING;2) raid5d() handles IO in a deadloop, until all IO are issued;3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;This behaviour is introduce before v2.6, and for consequence, if othercontext hold 'reconfig_mutex', and md_check_recovery() can't updatesuper_block, then raid5d() will waste one cpu 100% by the deadloop, until'reconfig_mutex' is released.Refer to the implementation from raid1 and raid10, fix this problem byskipping issue IO if MD_SB_CHANGE_PENDING is still set aftermd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'is released. Meanwhile, the hang problem will be fixed as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: netem: account for backlog updates from child qdiscIn general, 'qlen' of any classful qdisc should keep track of thenumber of packets that the qdisc itself and all of its children holds.In case of netem, 'qlen' only accounts for the packets in its internaltfifo. When netem is used with a child qdisc, the child qdisc can use'qdisc_tree_reduce_backlog' to inform its parent, netem, about createdor dropped SKBs. This function updates 'qlen' and the backlog statisticsof netem, but netem does not account for changes made by a child qdisc.'qlen' then indicates the wrong number of packets in the tfifo.If a child qdisc creates new SKBs during enqueue and informs its parentabout this, netem's 'qlen' value is increased. When netem dequeues thenewly created SKBs from the child, the 'qlen' in netem is not updated.If 'qlen' reaches the configured sch->limit, the enqueue function stopsworking, even though the tfifo is not full.Reproduce the bug:Ensure that the sender machine has GSO enabled. Configure netem as rootqdisc and tbf as its child on the outgoing interface of the machineas follows:$ tc qdisc add dev root handle 1: netem delay 100ms limit 100$ tc qdisc add dev parent 1:0 tbf rate 50Mbit burst 1542 latency 50msSend bulk TCP traffic out via this interface, e.g., by running an iPerf3client on the machine. Check the qdisc statistics:$ tc -s qdisc show dev Statistics after 10s of iPerf3 TCP test before the fix (note thatnetem's backlog > limit, netem stopped accepting packets):qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0Statistics after the fix:qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.The interface fully stops transferring packets and "locks". In this case,the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is atits limit and no more packets are accepted.This patch adds a counter for the entries in the tfifo. Netem's 'qlen' isonly decreased when a packet is returned by its dequeue function, and notduring enqueuing into the child qdisc. External updates to 'qlen' are thusaccounted for and only the behavior of the backlog statistics changes. Asin other qdiscs, 'qlen' then keeps track of how many packets are held innetem and all of its children. As before, sch->limit remains as themaximum number of packets in the tfifo. The same applies to netem'sbacklog statistics.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: core: config: Prevent OOB read in SS endpoint companion parsingusb_parse_ss_endpoint_companion() checks descriptor type before length,enabling a potentially odd read outside of the buffer size.Fix this up by checking the size first before looking at any of thefields in the descriptor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: There is an issue in CPython when using `bytes.decode("unicode_escape", error="ignore|replace")`. If you are not using the "unicode_escape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpython3_6m1_0 < 3.6.15-84.1 (version in image is 3.6.15-49.1).
-
Description: Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may allow an unauthenticated user to complete authentication without pairing credentials via adjacent access. An unauthenticated, adjacent attacker could impersonate a Bluetooth BR/EDR master or slave to pair with a previously paired remote device to successfully complete the authentication procedure without knowing the link key.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: aqc111: Fix out-of-bounds accesses in RX fixupaqc111_rx_fixup() contains several out-of-bounds accesses that can betriggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data.Found doing variant analysis. Tested it with another driver (ax88179_178a), sinceI don't have a aqc111 device to test it, but the code looks very similar.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: do not index invalid pin_assignmentsA poorly implemented DisplayPort Alt Mode port partner can indicatethat its pin assignment capabilities are greater than the maximumvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_showwill cause a BRK exception due to an out of bounds array access.Prevent for loop in pin_assignment_show from accessinginvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAXvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loopcondition.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools > 0-0 (version in image is 2.48.2-12.34.1).
-
Description: A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: **DISPUTED**A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.The default behavior when the stack-protector detects an overflow is to terminate your application, resulting in controlled loss of availability. An attacker who can exploit a buffer overflow without triggering the stack-protector might be able to change program flow control to cause an uncontrolled loss of availability or to go further and affect confidentiality or integrity. NOTE: The GCC project argues that this is a missed hardening bug and not a vulnerability by itself.
Packages affected:
- libgcc_s1 < 13.2.1+git7813-1.10.1 (version in image is 12.3.0+git1204-1.13.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A flaw was found in libssh. By utilizing the ProxyCommand or ProxyJump feature, users can exploit unchecked hostname syntax on the client. This issue may allow an attacker to inject malicious code into the command of the features mentioned through the hostname parameter.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: A defect was discovered in the Python "ssl" module where there is a memoryrace condition with the ssl.SSLContext methods "cert_store_stats()" and"get_ca_certs()". The race condition can be triggered if the methods arecalled at the same time as certificates are loaded into the SSLContext,such as during the TLS handshake with a certificate directory configured.This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.
Packages affected:
- libpython3_6m1_0 < 3.6.15-58.1 (version in image is 3.6.15-49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing anASN.1 Generalized Time field. If given an syntactically incorrect field, theparser might end up using -1 for the length of the *time fraction*, leading toa `strlen()` getting performed on a pointer to a heap buffer area that is not(purposely) null terminated.This flaw most likely leads to a crash, but can also lead to heap contentsgetting returned to the application when[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.89.1 (version in image is 8.0.1-11.74.1).
-
Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools > 0-0 (version in image is 2.48.2-12.34.1).
-
Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()Replace one-element array with a flexible-array member in `structmwifiex_ie_types_wildcard_ssid_params` to fix the following warningon a MT8173 Chromebook (mt8173-elm-hana):[ 356.775250] ------------[ cut here ]------------[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]The "(size 6)" above is exactly the length of the SSID of the networkthis device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len);There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on thisstruct, but it already didn't account for the size of the one-elementarray, so it doesn't need to be changed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in the Linux kernel before 5.14.15. There is an array-index-out-of-bounds flaw in the detach_capi_ctr function in drivers/isdn/capi/kcapi.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: footbridge: fix PCI interrupt mappingSince commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() inpci_device_probe()"), the PCI code will call the IRQ mapping functionwhenever a PCI driver is probed. If these are marked as __init, thiscauses an oops if a PCI driver is loaded or bound after the kernel hasinitialised.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix kernel panic caused by race of smc_sockA crash occurs when smc_cdc_tx_handler() tries to access smc_sockbut smc_release() has already freed it.[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88[ 4570.696048] #PF: supervisor write access in kernel mode[ 4570.696728] #PF: error_code(0x0002) - not-present page[ 4570.697401] PGD 0 P4D 0[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30<...>[ 4570.711446] Call Trace:[ 4570.711746] [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0[ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560[ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10[ 4570.713489] tasklet_action_common.isra.17+0x66/0x140[ 4570.714083] __do_softirq+0x123/0x2f4[ 4570.714521] irq_exit_rcu+0xc4/0xf0[ 4570.714934] common_interrupt+0xba/0xe0Though smc_cdc_tx_handler() checked the existence of smc connection,smc_release() may have already dismissed and released the smc socketbefore smc_cdc_tx_handler() further visits it.smc_cdc_tx_handler() |smc_release()if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freedbh_lock_sock(&smc->sk) (panic) |To make sure we won't receive any CDC messages after we free thesmc_sock, add a refcount on the smc_connection for inflight CDCmessage(posted to the QP but haven't received related CQE), anddon't release the smc_connection until all the inflight CDC messageshaven been done, for both success or failed ones.Using refcount on CDC messages brings another problem: when the linkis going to be destroyed, smcr_link_clear() will reset the QP, whichthen remove all the pending CQEs related to the QP in the CQ. To makesure all the CQEs will always come back so the refcount on thesmc_connection can always reach 0, smc_ib_modify_qp_reset() was replacedby smc_ib_modify_qp_error().And remove the timeout in smc_wr_tx_wait_no_pending_sends() since weneed to wait for all pending WQEs done, or we may encounter use-after-free when handling CQEs.For IB device removal routine, we need to wait for all the QPs on thatdevice been destroyed before we can destroy CQs on the device, orthe refcount on smc_connection won't reach 0 and smc_sock cannot bereleased.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: free queued packets when closing socketAs reported by syzbot [1], there is a memory leak while closing thesocket. We partially solved this issue with commit ac03046ece2b("vsock/virtio: free packets during the socket release"), but weforgot to drain the RX queue when the socket is definitely closed bythe scheduled work.To avoid future issues, let's use the new virtio_transport_remove_sock()to drain the RX queue before removing the socket from the af_vsock listscalling vsock_remove_sock().[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix bad pointer dereference when ehandler kthread is invalidCommit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")changed the allocation logic to call put_device() to perform host cleanupwith the assumption that IDA removal and stopping the kthread wouldproperly be performed in scsi_host_dev_release(). However, in the unlikelycase that the error handler thread fails to spawn, shost->ehandler is setto ERR_PTR(-ENOMEM).The error handler cleanup code in scsi_host_dev_release() will callkthread_stop() if shost->ehandler != NULL which will always be the casewhether the kthread was successfully spawned or not. In the case that itfailed to spawn this has the nasty side effect of trying to dereference aninvalid pointer when kthread_stop() is called. The following splat providesan example of this behavior in the wild:scsi host11: error handler thread failed to spawn, error = -4Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)BUG: Kernel NULL pointer dereference on read at 0x0000010cFaulting instruction address: 0xc00000000818e9a8Oops: Kernel access of bad area, sig: 11 [#1]LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeriesModules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region hash dm_log dm_mod fuse overlay squashfs loopCPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1NIP: c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8REGS: c000000037d12ea0 TRAP: 0300 Not tainted (5.13.0-rc7)MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28228228XER: 20040001CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffcGPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ffGPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffcNIP [c00000000818e9a8] kthread_stop+0x38/0x230LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160Call Trace:[c000000033bb2c48] 0xc000000033bb2c48 (unreliable)[c0000000089846e8] scsi_host_dev_release+0x98/0x160[c00000000891e960] device_release+0x60/0x100[c0000000087e55c4] kobject_release+0x84/0x210[c00000000891ec78] put_device+0x28/0x40[c000000008984ea4] scsi_host_alloc+0x314/0x430[c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi][c000000008110104] vio_bus_probe+0xa4/0x4b0[c00000000892a860] really_probe+0x140/0x680[c00000000892aefc] driver_probe_device+0x15c/0x200[c00000000892b63c] device_driver_attach+0xcc/0xe0[c00000000892b740] __driver_attach+0xf0/0x200[c000000008926f28] bus_for_each_dev+0xa8/0x130[c000000008929ce4] driver_attach+0x34/0x50[c000000008928fc0] bus_add_driver+0x1b0/0x300[c00000000892c798] driver_register+0x98/0x1a0[c00000000810eb60] __vio_register_driver+0x80/0xe0[c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi][c0000000080121d0] do_one_initcall+0x60/0x2d0[c000000008261abc] do_init_module+0x7c/0x320[c000000008265700] load_module+0x2350/0x25b0[c000000008265cb4] __do_sys_finit_module+0xd4/0x160[c000000008031110] system_call_exception+0x150/0x2d0[c00000000800d35c] system_call_common+0xec/0x278Fix this be nulling shost->ehandler when the kthread fails to spawn.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Avoid data corruptionsWait for all dependencies of a job to complete beforekilling it to avoid data corruptions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Update intermediate power state for SIUpdate the current state as boot state during dpm initialization.During the subsequent initialization, set_power_state gets called totransition to the final power state. set_power_state refers to valuesfrom the current state and without current state populated, it couldresult in NULL pointer dereference.For ex: on platforms where PCI speed change is supported through ACPIATCS method, the link speed of current state needs to be queried beforedeciding on changing to final power state's link speed. The logic to queryATCS-support was broken on certain platforms. The issue became visiblewhen broken ATCS-support logic got fixed with commitf9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/qeth: fix deadlock during failing recoveryCommit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removedtaking discipline_mutex inside qeth_do_reset(), fixing potentialdeadlocks. An error path was missed though, that still takesdiscipline_mutex and thus has the original deadlock potential.Intermittent deadlocks were seen when a qeth channel path is configuredoffline, causing a race between qeth_do_reset and ccwgroup_remove.Call qeth_set_offline() directly in the qeth_do_reset() error case andthen a new variant of ccwgroup_set_offline(), without takingdiscipline_mutex.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: do not allow call hns3_nic_net_open repeatedlyhns3_nic_net_open() is not allowed to called repeatly, but thereis no checking for this. When doing device reset and setup tcconcurrently, there is a small oppotunity to call hns3_nic_net_openrepeatedly, and cause kernel bug by calling napi_enable twice.The calltrace information is like below:[ 3078.222780] ------------[ cut here ]------------[ 3078.230255] kernel BUG at net/core/dev.c:6991![ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP[ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)[ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1[ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021[ 3078.276801] Workqueue: hclge hclge_service_task [hclge][ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)[ 3078.296168] pc : napi_enable+0x80/0x84tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3][ 3078.314771] sp : ffff8000108abb20[ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300[ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000[ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880[ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000[ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930[ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4[ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8[ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344[ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938[ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0[ 3078.414657] Call trace:[ 3078.418517] napi_enable+0x80/0x84[ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3][ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3][ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge][ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge][ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge][ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge][ 3078.475675] process_one_work+0x1dc/0x48c[ 3078.481888] worker_thread+0x15c/0x464[ 3078.487104] kthread+0x160/0x170[ 3078.492479] ret_from_fork+0x10/0x18[ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)[ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---Once hns3_nic_net_open() is excute success, the flagHNS3_NIC_STATE_DOWN will be cleared. So add checking for thisflag, directly return when HNS3_NIC_STATE_DOWN is no set.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Handle SRCU initialization failure during page track initCheck the return of init_srcu_struct(), which can fail due to OOM, wheninitializing the page track mechanism. Lack of checking leads to a NULLpointer deref found by a modified syzkaller.[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isdn: mISDN: Fix sleeping function called from invalid contextThe driver can call card->isac.release() function from an atomiccontext.Fix this by calling this function after releasing the lock.The following log reveals it:[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe[ 44.169574 ] INFO: lockdep is turned off.[ 44.169899 ] irq event stamp: 0[ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0[ 44.170627 ] hardirqs last disabled at (0): [] copy_process+0x132d/0x3e00[ 44.171240 ] softirqs last enabled at (0): [] copy_process+0x135a/0x3e00[ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0[ 44.172318 ] Preemption disabled at:[ 44.172320 ] [] nj_release+0x69/0x500 [netjet][ 44.174441 ] Call Trace:[ 44.174630 ] dump_stack_lvl+0xa8/0xd1[ 44.174912 ] dump_stack+0x15/0x17[ 44.175166 ] ___might_sleep+0x3a2/0x510[ 44.175459 ] ? nj_release+0x69/0x500 [netjet][ 44.175791 ] __might_sleep+0x82/0xe0[ 44.176063 ] ? start_flush_work+0x20/0x7b0[ 44.176375 ] start_flush_work+0x33/0x7b0[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0[ 44.177711 ] __flush_work+0x11a/0x1a0[ 44.177991 ] ? flush_work+0x20/0x20[ 44.178257 ] ? lock_release+0x13c/0x8f0[ 44.178550 ] ? __kasan_check_write+0x14/0x20[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20[ 44.179530 ] ? __kasan_check_read+0x11/0x20[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0[ 44.181189 ] ? kfree+0x13e/0x290[ 44.181438 ] flush_work+0x17/0x20[ 44.181695 ] mISDN_freedchannel+0xe8/0x100[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac][ 44.182366 ] nj_release+0xf6/0x500 [netjet][ 44.182685 ] nj_remove+0x48/0x70 [netjet][ 44.182989 ] pci_device_remove+0xa9/0x250
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Put LLD module refcnt after SCSI device is releasedSCSI host release is triggered when SCSI device is freed. We have to makesure that the low-level device driver module won't be unloaded before SCSIhost instance is released because shost->hostt is required in the releasehandler.Make sure to put LLD module refcnt after SCSI device is released.Fixes a kernel panic of 'BUG: unable to handle page fault for address'reported by Changhui and Yi.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_doneThe done() netlink callback nfc_genl_dump_ses_done() should check ifreceived argument is non-NULL, because its allocation could fail earlierin dumpit() (nfc_genl_dump_ses()).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix kernel panic during drive powercycle testWhile looping over shost's sdev list it is possible that oneof the drives is getting removed and its sas_target object isfreed but its sdev object remains intact.Consequently, a kernel panic can occur while the driver is trying to accessthe sas_address field of sas_target object without also checking thesas_target object for NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: improve robustness of the audit queue handlingIf the audit daemon were ever to get stuck in a stopped state thekernel's kauditd_thread() could get blocked attempting to send auditrecords to the userspace audit daemon. With the kernel threadblocked it is possible that the audit queue could grow unbounded ascertain audit record generating events must be exempt from the queuelimits else the system enter a deadlock state.This patch resolves this problem by lowering the kernel thread'ssocket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaksthe kauditd_send_queue() function to better manage the various auditqueues when connection problems occur between the kernel and theaudit daemon. With this patch, the backlog may temporarily growbeyond the defined limits when the audit daemon is stopped and thesystem is under heavy audit pressure, but kauditd_thread() willcontinue to make progress and drain the queues as it would for otherconnection problems. For example, with the audit daemon put into astopped state and the system configured to audit every syscall itwas still possible to shutdown the system without a kernel panic,deadlock, etc.; granted, the system was slow to shutdown but that isto be expected given the extreme pressure of recording every syscall.The timeout value of HZ/10 was chosen primarily throughexperimentation and this developer's "gut feeling". There is likelyno one perfect value, but as this scenario is limited in scope (rootprivileges would be needed to send SIGSTOP to the audit daemon), itis likely not worth exposing this as a tunable at present. This canalways be done at a later date if it proves necessary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pciehp: Fix infinite loop in IRQ handler upon power faultThe Power Fault Detected bit in the Slot Status register differs fromall other hotplug events in that it is sticky: It can only be clearedafter turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot.The stickiness used to cause interrupt storms and infinite loops whichwere fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power faultinterrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enablesoftware notification on empty slots").Unfortunately in 2020 the infinite loop issue was inadvertentlyreintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interruptrace"): The hardirq handler pciehp_isr() clears the PFD bit untilpciehp's power_fault_detected flag is set. That happens in the IRQthread pciehp_ist(), which never learns of the event because the hardirqhandler is stuck in an infinite loop. Fix by setting thepower_fault_detected flag already in the hardirq handler.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG")made the __qlt_24xx_handle_abts() function return early iftcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to cleanup the allocated memory for the management command.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: ca8210: Stop leaking skb'sUpon error the ieee802154_xmit_complete() helper is not called. Onlyieee802154_wake_queue() is called manually. We then leak the skbstructure.Free the skb structure upon error before returning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: Transitional solution for clcsock race issueWe encountered a crash in smc_setsockopt() and it is caused byaccessing smc->clcsock after clcsock was released. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53 RIP: 0010:smc_setsockopt+0x59/0x280 [smc] Call Trace: __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f16ba83918e This patch tries to fix it by holding clcsock_release_lock andchecking whether clcsock has already been released before access.In case that a crash of the same reason happens in smc_getsockopt()or smc_switch_to_fallback(), this patch also checkes smc->clcsockin them too. And the caller of smc_switch_to_fallback() will identifywhether fallback succeeds according to the return value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vt_ioctl: fix array_index_nospec in vt_setactivatearray_index_nospec ensures that an out-of-bounds value is set to zeroon the transient path. Decreasing the value by one afterwards causesa transient integer underflow. vsa.console should be decreased firstand then sanitized with array_index_nospec.Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, KavehRazavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VUAmsterdam.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: sdata can be NULL during AMPDU startieee80211_tx_ba_session_handle_start() may get NULL for sdata when adeauthentication is ongoing.Here a trace triggering the race with the hostapd testmulti_ap_fronthaul_on_ap:(gdb) list *drv_ampdu_action+0x460x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).391 int ret = -EOPNOTSUPP;392393 might_sleep();394395 sdata = get_bss_sdata(sdata);396 if (!check_sdata_in_driver(sdata))397 return -EIO;398399 trace_drv_ampdu_action(local, sdata, params);400wlan0: moving STA 02:00:00:00:03:00 to state 3wlan0: associatedwlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)wlan0: moving STA 02:00:00:00:03:00 to state 2wlan0: moving STA 02:00:00:00:03:00 to state 1wlan0: Removed STA 02:00:00:00:03:00wlan0: Destroyed STA 02:00:00:00:03:00BUG: unable to handle page fault for address: fffffffffffffb48PGD 11814067 P4D 11814067 PUD 11816067 PMD 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014Workqueue: phy3 ieee80211_ba_session_work [mac80211]RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0Call Trace: ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: make apf token non-zero to fix bugIn current async pagefault logic, when a page is ready, KVM relies onkvm_arch_can_dequeue_async_page_present() to determine whether to delivera READY event to the Guest. This function test token value of structkvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when aREADY event is finished by Guest. If value is zero meaning that a READYevent is done, so the KVM can deliver another.But the kvm_arch_setup_async_pf() may produce a valid token with zerovalue, which is confused with previous mention and may lead the loss ofthis READY event.This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: fix memory leak in gpiochip_setup_dev()Here is a backtrace report about memory leak detected ingpiochip_setup_dev():unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_keygcdev_register() & gcdev_unregister() would call device_add() &device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) toregister/unregister device.However, if device_add() succeeds, some resource (likestruct device_private allocated by device_private_init())is not released by device_del().Therefore, after device_add() succeeds by gcdev_register(), itneeds to call put_device() to release resource in the error handlepath.Here we move forward the register of release function, and let itrelease every piece of resource by put_device() instead of kfree().While at it, fix another subtle issue, i.e. when gc->ngpio is equalto 0, we still call kcalloc() and, in case of further error, kfree()on the ZERO_PTR pointer, which is not NULL. It's not a bug per se,but rather waste of the resources and potentially wrong expectationabout contents of the gdev->descs variable.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: call genl_unregister_family() first in nbd_cleanup()Otherwise there may be race between module removal and the handling ofnetlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix race between nbd_alloc_config() and module removalWhen nbd module is being removing, nbd_alloc_config() may becalled concurrently by nbd_genl_connect(), although try_module_get()will return false, but nbd_alloc_config() doesn't handle it.The race may lead to the leak of nbd_config and its relatedresources (e.g, recv_workq) and oops in nbd_read_stat() dueto the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30Fixing it by checking the return value of try_module_get()in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),assign nbd->config only when nbd_alloc_config() succeeds to ensurethe value of nbd->config is binary (valid or NULL).Also adding a debug message to check the reference counterof nbd_config during module removal.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix SCSI I/O completion and abort handler deadlockDuring stress I/O tests with 500+ vports, hard LOCKUP call traces areobserved.CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7fCPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1fDiagram of lockup:CPUA CPUB---- ----lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lockphba->hbalockFix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock inlpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lockfirst before phba->hbalock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_prot_sock.sysctl_ip_prot_sock is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_llm_reports.While reading sysctl_igmp_llm_reports, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_mapHere is the BUG report by KASAN about null pointer dereference:BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50Read of size 1 at addr 0000000000000000 by task python3/2640Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_mapkasprintf() would return NULL pointer when kmalloc() fail to allocate.So directly return ENOMEM, if kasprintf() return NULL pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix UAF in ieee80211_scan_rx()ieee80211_scan_rx() tries to access scan_req->flags after anull check, but a UAF is observed when the scan is completedand __ieee80211_scan_completed() executes, which then callscfg80211_scan_done() leading to the freeing of scan_req.Since scan_req is rcu_dereference()'d, prevent the racing in__ieee80211_scan_completed() by ensuring that from mac80211'sPOV it is no longer accessed from an RCU read critical sectionbefore we call cfg80211_scan_done().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: fix oops in concurrently setting insn_emulation sysctlsemulation_proc_handler() changes table->data for proc_dointvec_minmaxand can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200To fix this issue, keep the table->data as &insn->current_mode anduse container_of() to retrieve the insn pointer. Another mutex isused to protect against the current_mode update but not for retrievinginsn_emulation as table->data is no longer changing.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix a race condition between login_work and the login threadIn case a malicious initiator sends some random data immediately after alogin PDU; the iscsi_target_sk_data_ready() callback will schedule thelogin_work and, at the same time, the negotiation may end without clearingthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges arerequired to complete the login).The login has been completed but the login_work function will find theLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from reschedulingitself; at this point, if the initiator drops the connection, theiscsit_conn structure will be freed, login_work will dereference a releasedsocket structure and the kernel crashes.BUG: kernel NULL pointer dereference, address: 0000000000000230PF: supervisor write access in kernel modePF: error_code(0x0002) - not-present pageWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]RIP: 0010:_raw_read_lock_bh+0x15/0x30Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0Fix this bug by forcing login_work to stop after the login has beencompleted and the socket callbacks have been restored.Add a comment to clearify the return values of iscsi_target_do_login()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: call __btrfs_remove_free_space_cache_locked on cache load failureNow that lockdep is staying enabled through our entire CI runs I startedseeing the following stack in generic/475------------[ cut here ]------------WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014Workqueue: btrfs-cache btrfs_work_helperRIP: 0010:btrfs_discard_update_discardable+0x98/0xb0RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831eRBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock);We have a temporary free space ctl for loading the free space cache inorder to avoid having allocations happening while we're loading thecache. When we hit an error we free it all up, however this also callsbtrfs_discard_update_discardable, which requiresblock_group->free_space_ctl->tree_lock to be held. However this is ourtemporary ctl so this lock isn't held. Fix this by calling__btrfs_remove_free_space_cache_locked instead so that we only clean upthe entries and do not mess with the discardable stats.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:class: fix possible memory leak in __class_register()If class_add_groups() returns error, the 'cp->subsys' need beunregister, and the 'cp' need be freed.We can not call kset_unregister() here, because the 'cls' willbe freed in callback function class_release() and it's alsofreed in caller's error path, it will cause double free.So fix this by calling kobject_del() and kfree_const(name) tocleanup kobject. Besides, call kfree() to free the 'cp'.Fault injection test can trigger this:unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49aunreferenced object 0xffff888037274000 (size 1024): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probeof_phy_find_device() return device node with refcount incremented.Call put_device() to relese it when not needed anymore.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb()It is possible that skb is freed in ath9k_htc_rx_msg(), thenusb_submit_urb() fails and we try to free skb again. It causesuse-after-free bug. Moreover, if alloc_skb() fails, urb->context becomesNULL but rx_buf is not freed and there can be a memory leak.The patch removes unnecessary nskb and makes skb processing more clear: itis supposed that ath9k_htc_rx_msg() either frees old skb or passes itsmanaging to another callback function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: A memory leak flaw was found in the Linux kernel's Stream Control Transmission Protocol. This issue may occur when a user starts a malicious networking service and someone connects to this service. This could allow a local user to starve resources, causing a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent mss overflow in skb_segment()Once again syzbot is able to crash the kernel in skb_segment() [1]GSO_BY_FRAGS is a forbidden value, but unfortunately the followingcomputation in skb_segment() can reach it quite easily : mss = mss * partial_segs;65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead toa bad final result.Make sure to limit segmentation so that the new mss value is smallerthan GSO_BY_FRAGS.[1]general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53__skb_gso_segment+0x339/0x710 net/core/gso.c:124skb_gso_segment include/net/gso.h:83 [inline]validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338dev_queue_xmit include/linux/netdevice.h:3134 [inline]packet_xmit+0x257/0x380 net/packet/af_packet.c:276packet_snd net/packet/af_packet.c:3087 [inline]packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119sock_sendmsg_nosec net/socket.c:730 [inline]__sock_sendmsg+0xd5/0x180 net/socket.c:745__sys_sendto+0x255/0x340 net/socket.c:2190__do_sys_sendto net/socket.c:2202 [inline]__se_sys_sendto net/socket.c:2198 [inline]__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x63/0x6bRIP: 0033:0x7f8692032aa9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/lbr: Filter vsyscall addressesWe found that a panic can occur when a vsyscall is made while LBR samplingis active. If the vsyscall is interrupted (NMI) for perf sampling, thiscall sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler()Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i)Within this macro, this dereference occurs: (insn)->next_byteInspecting registers at this point, the value of the next_byte field is theaddress of the vsyscall made, for example the location of the vsyscallversion of gettimeofday() at 0xffffffffff600000. The access to an addressin the vsyscall region will trigger an oops due to an unhandled page fault.To fix the bug, filtering for vsyscalls can be done whendetermining the branch type. This patch will returna "none" branch if a kernel address if found to lie in thevsyscall region.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: Add mutex lock in control vblank irqAdd a mutex lock to control vblank irq to synchronize vblankenable/disable operations happening from different threads to preventrace conditions while registering/unregistering the vblank irq callback.v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a parameter of dpu_encoder_phys. -Switch from atomic refcnt to a simple int counter as mutex has now been addedv3: Mistakenly did not change wording in last version. It is done now.v2: Slightly changed wording of commit messagePatchwork: https://patchwork.freedesktop.org/patch/571854/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/ipoib: Fix mcast list lockingReleasing the `priv->lock` while iterating the `priv->multicast_list` in`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` toremove the items while in the middle of iteration. If the mcast is removedwhile the lock was dropped, the for loop spins forever resulting in a hardlockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below) -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.)Fix this by keeping the lock held and changing to GFP_ATOMIC to preventeventual sleeps.Unfortunately we could not reproduce the lockup and confirm this fix butbased on the code review I think this fix should address such lockups.crash> bc 31PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"-- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018--- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967crash> rx ff646f199a8c7e68ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.workcrash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000(empty)crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000crash> b 8PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"-- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: s390: fix setting of fpc registerkvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control(fpc) register of a guest cpu. The new value is tested for validity bytemporarily loading it into the fpc register.This may lead to corruption of the fpc register of the host process:if an interrupt happens while the value is temporarily loaded into the fpcregister, and within interrupt context floating point or vector registersare used, the current fp/vx registers are saved with save_fpu_regs()assuming they belong to user space and will be loaded into fp/vx registerswhen returning to user space.test_fp_ctl() restores the original user space / host process fpc registervalue, however it will be discarded, when returning to user space.In result the host process will incorrectly continue to run with the valuethat was supposed to be used for a guest cpu.Fix this by simply removing the test. There is another test right beforethe SIE context is entered which will handles invalid values.This results in a change of behaviour: invalid values will now be acceptedinstead of that the ioctl fails with -EINVAL. This seems to be acceptable,given that this interface is most likely not used anymore, and this is inaddition the same behaviour implemented with the memory mapped interface(replace invalid values with zero) - see sync_regs() in kvm-s390.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sdio: fix possible resource leaks in some error pathsIf sdio_add_func() or sdio_init_func() fails, sdio_remove_func() cannot release the resources, because the sdio function is not presentedin these two cases, it won't call of_node_put() or put_device().To fix these leaks, make sdio_func_present() only control whetherdevice_del() needs to be called or not, then always call of_node_put()and put_device().In error case in sdio_init_func(), the reference of 'card->dev' isnot get, to avoid redundant put in sdio_free_func_cis(), move theget_device() to sdio_alloc_func() and put_device() to sdio_release_func(),it can keep the get/put function be balanced.Without this patch, while doing fault inject test, it can get thefollowing leak reports, after this fix, the leak is gone.unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Restore allocated resources on failed copyoutFix a resource leak if an error occurs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: stop the device in bond_setup_by_slave()Commit 9eed321cde22 ("net: lapbether: only support ethernet devices")has been able to keep syzbot away from net/lapb, until today.In the following splat [1], the issue is that a lapbether device hasbeen created on a bonding device without members. Then adding a nonARPHRD_ETHER member forced the bonding master to change its type.The fix is to make sure we call dev_close() in bond_setup_by_slave()so that the potential linked lapbether devices (or any other deviceshaving assumptions on the physical device) are removed.A similar bug has been addressed in commit 40baec225765("bonding: fix panic on non-ARPHRD_ETHER enslave failure")[1]skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0kernel BUG at net/core/skbuff.c:192 !Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_panic net/core/skbuff.c:188 [inline]pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202lr : skb_panic net/core/skbuff.c:188 [inline]lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202sp : ffff800096a06aa0x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7beax23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11cx2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086Call trace:skb_panic net/core/skbuff.c:188 [inline]skb_under_panic+0x13c/0x140 net/core/skbuff.c:202skb_push+0xf0/0x108 net/core/skbuff.c:2446ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384dev_hard_header include/linux/netdevice.h:3136 [inline]lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1970 [inline]call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]call_netdevice_notifiers net/core/dev.c:2022 [inline]__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508dev_close_many+0x1e0/0x470 net/core/dev.c:1559dev_close+0x174/0x250 net/core/dev.c:1585lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1970 [inline]call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]call_netdevice_notifiers net/core/dev.c:2022 [inline]__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508dev_close_many+0x1e0/0x470 net/core/dev.c:1559dev_close+0x174/0x250 net/core/dev.c:1585bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539dev_ifsioc+0x754/0x9acdev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217sock_ioctl+0x4e8/0x834 net/socket.c:1322vfs_ioctl fs/ioctl.c:51 [inline]__do_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ibmvfc: Remove BUG_ON in the case of an empty event poolIn practice the driver should never send more commands than are allocatedto a queue's event pool. In the unlikely event that this happens, the codeasserts a BUG_ON, and in the case that the kernel is not configured tocrash on panic returns a junk event pointer from the empty event listcausing things to spiral from there. This BUG_ON is a historical artifactof the ibmvfc driver first being upstreamed, and it is well known now thatthe use of BUG_ON is bad practice except in the most unrecoverablescenario. There is nothing about this scenario that prevents the driverfrom recovering and carrying on.Remove the BUG_ON in question from ibmvfc_get_event() and return a NULLpointer in the case of an empty event pool. Update all call sites toibmvfc_get_event() to check for a NULL pointer and perfrom the appropriatefailure or recovery action.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hid: cp2112: Fix duplicate workqueue initializationPreviously the cp2112 driver called INIT_DELAYED_WORK withincp2112_gpio_irq_startup, resulting in duplicate initilizations of theworkqueue on subsequent IRQ startups following an initial request. Thisresulted in a warning in set_work_data in workqueue.c, as well as a rareNULL dereference within process_one_work in workqueue.c.Initialize the workqueue within _probe instead.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Fix null pointer dereference when host diesMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not raceand cause null pointer dereference when host suddenly dies.Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]virt device at the same time that xhci_kill_endpoint_urbs() tries toloop through all the device's endpoints, checking if there are anycancelled urbs left to give back.hold the xhci spinlock while freeing the virt device
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_noneAfter grabbing q->sysfs_lock, q->elevator may become NULL because ofelevator switch.Fix the NULL dereference on q->elevator by checking it with lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: call kmem_cache_destroy() in dm_integrity_init() error pathOtherwise the journal_io_cache will leak if dm_register_target() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: fix memory leak of remain_skbshif_dev->remain_skb is allocated and used exclusively inath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb isprocessed and subsequently freed (in error paths) only during the nextcall of ath9k_hif_usb_rx_stream().So, if the urbs are deallocated between those two calls due to the devicedeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()is not called next time and the allocated remain_skb is leaked. Our localSyzkaller instance was able to trigger that.remain_skb makes sense when receiving two consecutive urbs which arelogically linked together, i.e. a specific data field from the first skbindicates a cached skb to be allocated, memcpy'd with some data andsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbsdeallocation supposedly makes that link irrelevant so we need to free thecached skb in those cases.Fix the leak by introducing a function to explicitly free remain_skb (ifit is not NULL) when the rx urbs have been deallocated. remain_skb is NULLwhen it has not been allocated at all (hif_dev struct is kzalloced) orwhen it has been processed in next call to ath9k_hif_usb_rx_stream().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: rockchip: Fix refcount leak in rockchip_pinctrl_parse_groupsof_find_node_by_phandle() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:autofs: fix memory leak of waitqueues in autofs_catatonic_modeSyzkaller reports a memory leak:BUG: memory leakunreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:870 [inline] [] __se_sys_ioctl fs/ioctl.c:856 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdautofs_wait_queue structs should be freed if their wait_ctr becomes zero.Otherwise they will be lost.In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a newwaitqueue struct is allocated in autofs_wait(), its initial wait_ctrequals 2. After that wait_event_killable() is interrupted (it returns-ERESTARTSYS), so that 'wq->name.name == NULL' condition may be notsatisfied. Actually, this condition can be satisfied whenautofs_wait_release() or autofs_catatonic_mode() is called and, what isalso important, wait_ctr is decremented in those places. Upon the exit ofautofs_wait(), wait_ctr is decremented to 1. Then the unmounting processbegins: kill_sb calls autofs_catatonic_mode(), which should have freed thewaitqueues, but it only decrements its usage counter to zero which is nota correct behaviour.edit:imkThis description is of course not correct. The umount performed as a resultof an expire is a umount of a mount that has been automounted, it's not theautofs mount itself. They happen independently, usually after everythingmounted within the autofs file system has been expired away. If everythinghasn't been expired away the automount daemon can still exit leaving mountsin place. But expires done in both cases will result in a notification thatcalls autofs_wait_release() with a result status. The problem case is thesummary execution of of the automount daemon. In this case any waitingprocesses won't be woken up until either they are terminated or the mountis umounted.end edit: imkSo in catatonic mode we should free waitqueues which counter becomes zero.edit: imkInitially I was concerned that the calling of autofs_wait_release() andautofs_catatonic_mode() was not mutually exclusive but that can't be thecase (obviously) because the queue entry (or entries) is removed from thelist when either of these two functions are called. Consequently the waitentry will be freed by only one of these functions or by the woken processin autofs_wait() depending on the order of the calls.end edit: imk
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amba: bus: fix refcount leakcommit 5de1540b7bc4 ("drivers/amba: create devices from device tree")increases the refcount of of_node, but not releases it inamba_device_release, so there is refcount leak. By using of_node_putto avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- pam > 0-0 (version in image is 1.1.8-24.49.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/PM: Drain runtime-idle callbacks before driver removalA race condition between the .runtime_idle() callback and the .remove()callback in the rtsx_pcr PCI driver leads to a kernel crash due to anunhandled page fault [1].The problem is that rtsx_pci_runtime_idle() is not expected to be runningafter pm_runtime_get_sync() has been called, but the latter doesn't reallyguarantee that. It only guarantees that the suspend and resume callbackswill not be running when it returns.However, if a .runtime_idle() callback is already running whenpm_runtime_get_sync() is called, the latter will notice that the runtime PMstatus of the device is RPM_ACTIVE and it will return right away withoutwaiting for the former to complete. In fact, it cannot wait for.runtime_idle() to complete because it may be called from that callback (itarguably does not make much sense to do that, but it is not strictlyprohibited).Thus in general, whoever is providing a .runtime_idle() callback needsto protect it from running in parallel with whatever code runs afterpm_runtime_get_sync(). [Note that .runtime_idle() will not start afterpm_runtime_get_sync() has returned, but it may continue running then if ithas started earlier.]One way to address that race condition is to call pm_runtime_barrier()after pm_runtime_get_sync() (not before it, because a nonzero value of theruntime PM usage counter is necessary to prevent runtime PM callbacks frombeing invoked) to wait for the .runtime_idle() callback to complete shouldit be running at that point. A suitable place for doing that is inpci_device_remove() which calls pm_runtime_get_sync() before removing thedriver, so it may as well call pm_runtime_barrier() subsequently, whichwill prevent the race in question from occurring, not just in the rtsx_pcrdriver, but in any PCI drivers providing .runtime_idle() callbacks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix lock ordering potential deadlock in cifs_sync_mid_resultCoverity spotted that the cifs_sync_mid_result function could deadlock"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquireslock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()syzbot reported that nf_reinject() could be called without rcu_read_lock() :WARNING: suspicious RCU usage6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not taintednet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 12 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172stack backtrace:CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes thehbalock. Thus, lpfc_worker_wake_up() should not be called while holding thehbalock to avoid potential deadlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueueFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() whichsyzbot reported [1].[1]BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueuewrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75value changed: 0xffffffff83d7feb0 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointerdereference in sk_psock_verdict_data_ready()") fixed one NULL pointersimilarly due to no protection of saved_data_ready. Here is anotherdifferent caller causing the same issue because of the same reason. Sowe should protect it with sk_callback_lock read lock because the writerside in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".To avoid errors that could happen in future, I move those two pairs oflock into the sk_psock_data_ready(), which is suggested by John Fastabend.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: sync all devices to wait all processes being evictedIf there are more than one device doing reset in parallel, the firstdevice will call kfd_suspend_all_processes() to evict all processeson all devices, this call takes time to finish. other device willstart reset and recover without waiting. if the process has not beenevicted before doing recover, it will be restored, then caused pagefault.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move NPIV's transport unregistration to after resource clean upThere are cases after NPIV deletion where the fabric switch still believesthe NPIV is logged into the fabric. This occurs when a vport isunregistered before the Remove All DA_ID CT and LOGO ELS are sent to thefabric.Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs includingthe fabric D_ID, removes the last ndlp reference and frees the ndlp rportobject. This sometimes causes the race condition where the final DA_ID andLOGO are skipped from being sent to the fabric switch.Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_IDand LOGO are sent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix a possible memleak in tipc_buf_append__skb_linearize() doesn't free the skb when it fails, so move'*buf = NULL' after __skb_linearize(), so that the skb can befreed on the err path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()If we fail to allocate propname buffer, we need to drop the referencecount we just took. Because the pinctrl_dt_free_maps() includes thedroping operation, here we call it directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix seg fault in rxe_comp_queue_pktIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to theresp_pkts queue and then a decision is made whether to run the completertask inline or schedule it. Finally the skb is dereferenced to bump a 'hw'performance counter. This is wrong because if the completer task isalready running in a separate thread it may have already processed the skband freed it which can cause a seg fault. This has been observedinfrequently in testing at high scale.This patch fixes this by changing the order of enqueuing the packet untilafter the counter is accessed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: remove .ndo_poll_controller to avoid deadlocksThere is a deadlock issue found in sungem driver, please refer to thecommit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoiddeadlocks"). The root cause of the issue is that netpoll is in atomiccontext and disable_irq() is called by .ndo_poll_controller interfaceof sungem driver, however, disable_irq() might sleep. After analyzingthe implementation of fec_poll_controller(), the fec driver should havethe same issue. Due to the fec driver uses NAPI for TX completions, the.ndo_poll_controller is unnecessary to be implemented in the fec driver,so fec_poll_controller() can be safely removed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: Set lower bound of start tick timeCurrently ALSA timer doesn't have the lower limit of the start ticktime, and it allows a very small size, e.g. 1 tick with 1ns resolutionfor hrtimer. Such a situation may lead to an unexpected RCU stall,where the callback repeatedly queuing the expire update, as reportedby fuzzer.This patch introduces a sanity check of the timer start tick time, sothat the system returns an error when a too small start size is set.As of this patch, the lower limit is hard-coded to 100us, which issmall enough but can still work somehow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash problem in concurrent scenarioWhen link status change, the nic driver need to notify the rocedriver to handle this event, but at this time, the roce drivermay uninit, then cause kernel crash.To fix the problem, when link status change, need to checkwhether the roce registered, and when uninit, need to wait linkupdate finish.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix races between hole punching and AIO+DIOAfter commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",fstests/generic/300 become from always failed to sometimes failed:========================================================================[ 473.293420 ] run fstests generic/300[ 475.296983 ] JBD2: Ignoring recovery information on journal[ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.[ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found[ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.[ 494.292018 ] OCFS2: File system is now read-only.[ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30[ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072=========================================================================In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwrittenextents to a list. extents are also inserted into extent tree inocfs2_write_begin_nolock. Then another thread call fallocate to puch ahole at one of the unwritten extent. The extent at cpos was removed byocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_listfound there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlockocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_semIn most filesystems, fallocate is not compatible with racing with AIO+DIO,so fix it by adding to wait for all dio before fallocate/punch_hole likeext4.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: lpi2c: Avoid calling clk_get_rate during transferInstead of repeatedly calling clk_get_rate for each transfer, lockthe clock rate and cache the value.A deadlock has been observed while adding tlv320aic32x4 audio codec tothe system. When this clock provider adds its clock, the clk mutex islocked already, it needs to access i2c, which in return needs the mutexfor clk_get_rate as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: add the option to have a tty reject a new ldisc... and use it to limit the virtual terminals to just N_TTY. They arekind of special, and in particular, the "con_write()" routine violatesthe "writes cannot sleep" rule that some ldiscs rely on.This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659when N_GSM has been attached to a virtual console, and gsmld_write()calls con_write() while holding a spinlock, and con_write() then triesto get the console lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: imx: Introduce timeout when waiting on transmitter emptyBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potentialdeadlock.In case of the timeout, there is not much we can do, so we simply ignorethe transmitter state and optimistically try to continue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: cancel all works upon hci_unregister_dev()syzbot is reporting that calling hci_release_dev() from hci_error_reset()due to hci_dev_put() from hci_error_reset() can cause deadlock atdestroy_workqueue(), for hci_error_reset() is called fromhdev->req_workqueue which destroy_workqueue() needs to flush.We need to make sure that hdev->{rx_work,cmd_work,tx_work} which arequeued into hdev->workqueue and hdev->{power_on,error_reset} which arequeued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue);are called from hci_release_dev().Call cancel_work_sync() on these work items from hci_unregister_dev()as soon as hdev->list is removed from hci_dev_list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: avoid possible crash when edev->pdev changesIf a PCI device is removed during eeh_pe_report_edev(), edev->pdevwill change and can cause a crash, hold the PCI rescan/remove lockwhile taking a copy of edev->pdev->bus.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memcg: protect concurrent access to mem_cgroup_idrCommit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure aftermany small jobs") decoupled the memcg IDs from the CSS ID space to fix thecgroup creation failures. It introduced IDR to maintain the memcg IDspace. The IDR depends on external synchronization mechanisms formodifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()happen within css callback and thus are protected through cgroup_mutexfrom concurrent modifications. However idr_remove() for mem_cgroup_idrwas not protected against concurrency and can be run concurrently fordifferent memcgs when they hit their refcnt to zero. Fix that.We have been seeing list_lru based kernel crashes at a low frequency inour fleet for a long time. These crashes were in different part oflist_lru code including list_lru_add(), list_lru_del() and reparentingcode. Upon further inspection, it looked like for a given object (dentryand inode), the super_block's list_lru didn't have list_lru_one for thememcg of that object. The initial suspicions were either the object isnot allocated through kmem_cache_alloc_lru() or somehowmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg butreturned success. No evidence were found for these cases.Looking more deeply, we started seeing situations where valid memcg's idis not present in mem_cgroup_idr and in some cases multiple valid memcgshave same id and mem_cgroup_idr is pointing to one of them. So, the mostreasonable explanation is that these situations can happen due to racebetween multiple idr_remove() calls or race betweenidr_alloc()/idr_replace() and idr_remove(). These races are causingmultiple memcgs to acquire the same ID and then offlining of one of themwould cleanup list_lrus on the system for all of them. Later access fromother memcgs to the list_lru cause crashes due to missing list_lru_one.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() when freeing tree block after errorWhen freeing a tree block, at btrfs_free_tree_block(), if we fail tocreate a delayed reference we don't deal with the error and just do aBUG_ON(). The error most likely to happen is -ENOMEM, and we have acomment mentioning that only -ENOMEM can happen, but that is not true,because in case qgroups are enabled any error returned frombtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returnedfrom btrfs_search_slot() for example) can be propagated back tobtrfs_free_tree_block().So stop doing a BUG_ON() and return the error to the callers and makethem abort the transaction to prevent leaking space. Syzbot wastriggering this, likely due to memory allocation failure injection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Add missing bridge lock to pci_bus_lock()One of the true positives that the cfg_access_lock lockdep effortidentified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120Where pci_reset_bus() users are triggering unlocked secondary bus resets.Ironically pci_bus_reset(), several calls down from pci_reset_bus(), usespci_bus_lock() before issuing the reset which locks everything *but* thebridge itself.For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge);to pci_reset_function() for the "bus" and "cxl_bus" reset cases, addpci_dev_lock() for @bus->self to pci_bus_lock().[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: Use sequential access to access desc->pinmux dataWhen two client of the same gpio call pinctrl_select_state() for thesame functionality, we are seeing NULL pointer issue while accessingdesc->mux_owner.Let's say two processes A, B executing in pin_request() for the same pinand process A updates the desc->mux_usecount but not yet updated thedesc->mux_owner while process B see the desc->mux_usecount which gotupdated by A path and further executes strcmp and while accessingdesc->mux_owner it crashes with NULL pointer.Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B)pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfs: fix race between evice_inodes() and find_inode()&iput()Hi, allRecently I noticed a bug[1] in btrfs, after digged it intoand I believe it'a race in vfs.Let's assume there's a inode (ie ino 261) with i_count 1 iscalled by iput(), and there's a concurrent thread callinggeneric_shutdown_super().cpu0: cpu1:iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock()// note here: the inode 261// was still at sb list and hash list,// and I_FREEING|I_WILL_FREE was not been setbtrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEINGiput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()Now, we have two threads simultaneously evictingthe same inode, which may trigger the BUG(inode->i_state & I_CLEAR)statement both within clear_inode() and iput().To fix the bug, recheck the inode->i_count after holding i_lock.Because in the most scenarios, the first check is valid, andthe overhead of spin_lock() can be reduced.If there is any misunderstanding, please let me know, thanks.[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()return false when I reproduced the bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a NULL pointer dereference when failed to start a new trasacntion[BUG]Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[CAUSE]The allocation failure happens at the start_transaction() insideprepare_to_relocate(), and during the error handling we callunset_reloc_control(), which makes fs_info->balance_ctl to be NULL.Then we continue the error path cleanup in btrfs_balance() by callingreset_balance_state() which will call del_balance_item() to fully deletethe balance item in the root tree.However during the small window between set_reloc_contrl() andunset_reloc_control(), we can have a subvolume tree update and created areloc_root for that subvolume.Then we go into the final btrfs_commit_transaction() ofdel_balance_item(), and into btrfs_update_reloc_root() insidecommit_fs_roots().That function checks if fs_info->reloc_ctl is in the merge_reloc_treestage, but since fs_info->reloc_ctl is NULL, it results a NULL pointerdereference.[FIX]Just add extra check on fs_info->reloc_ctl insidebtrfs_update_reloc_root(), before checkingfs_info->reloc_ctl->merge_reloc_tree.That DEAD_RELOC_TREE handling is to prevent further modification to thereloc tree during merge stage, but since there is no reloc_ctl at all,we do not need to bother that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix i_data_sem unlock order in ext4_ind_migrate()Fuzzing reports a possible deadlock in jbd2_log_wait_commit.This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to requiresynchronous updates because the file descriptor is opened with O_SYNC.This can lead to the jbd2_journal_stop() function callingjbd2_might_wait_for_commit(), potentially causing a deadlock if theEXT4_IOC_MIGRATE call races with a write(2) system call.This problem only arises when CONFIG_PROVE_LOCKING is enabled. In thiscase, the jbd2_might_wait_for_commit macro locks jbd2_handle in thejbd2_journal_stop function while i_data_sem is locked. This triggerslockdep because the jbd2_journal_start function might also lock the samejbd2_handle simultaneously.Found by Linux Verification Center (linuxtesting.org) with syzkaller.Rule: add
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlegacy: Clear stale interrupts before resuming deviceiwl4965 fails upon resume from hibernation on my laptop. The reasonseems to be a stale interrupt which isn't being cleared out beforeinterrupts are enabled. We end up with a race beween the resumetrying to bring things back up, and the restart work (queued formthe interrupt handler) trying to bring things down. Eventuallythe whole thing blows up.Fix the problem by clearing out any stale interrupts beforeinterrupts get enabled during resume.Here's a debug log of the indicent:[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000[ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000[ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload[ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282[ 12.052207] ieee80211 phy0: il4965_mac_start enter[ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff[ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready[ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions[ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S[ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm[ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm[ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK[ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations[ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up[ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.[ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down[ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout[ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort[ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver[ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared[ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state[ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master[ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.[ 12.058869] ieee80211 phy0: Hardware restart was requested[ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.[ 16.132303] ------------[ cut here ]------------[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010[ 16.132463] Workqueue: async async_run_entry_fn[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132501] Code: da 02 00 0---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.237.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Move events notifier registration to be after device registrationMove pkey change work initialization and cleanup from device resourcesstage to notifier stage, since this is the stage which handles this workevents.Fix a race between the device deregistration and pkey change work by movingMLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order toensure that the notifier is deregistered before the device during cleanup.Which ensures there are no works that are being executed after thedevice has already unregistered which can cause the panic below.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023Workqueue: events pkey_change_handler [mlx5_ib]RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]process_one_work+0x1e8/0x3c0worker_thread+0x50/0x3b0? rescuer_thread+0x380/0x380kthread+0x149/0x170? set_kthread_struct+0x50/0x50ret_from_fork+0x22/0x30Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]CR2: 0000000000000000---[ end trace f6f8be4eae12f7bc ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: IDLETIMER: Fix for possible ABBA deadlockDeletion of the last rule referencing a given idletimer may happen atthe same time as a read of its file in sysfs:| ======================================================| WARNING: possible circular locking dependency detected| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted| ------------------------------------------------------| iptables/3303 is trying to acquire lock:| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20|| but task is already holding lock:| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]|| which lock already depends on the new lock.A simple reproducer is:| #!/bin/bash|| while true; do| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| done &| while true; do| cat /sys/class/xt_idletimer/timers/testme >/dev/null| doneAvoid this by freeing list_mutex right after deleting the element fromthe list, then continuing with the teardown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: util: Avoid accessing a ringbuffer not initialized yetIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer isfully initialized, we can hit the panic below:hv_utils: Registering HyperV Utility Driverhv_vmbus: registering driver hv_utils...BUG: kernel NULL pointer dereference, address: 0000000000000000CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1RIP: 0010:hv_pkt_iter_first+0x12/0xd0Call Trace:... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 asm_sysvec_hyperv_stimer0... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_readThis can happen because the KVP/VSS channel callback can be invokedeven before the channel is fully opened:1) as soon as hv_kvp_init() -> hvutil_transport_init() creates/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately andregister itself to the driver by writing a message KVP_OP_REGISTER1 to thefile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) andreading the file for the driver's response, which is handled byhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().2) the problem with kvp_register_done() is that it can cause thechannel callback to be called even before the channel is fully opened,and when the channel callback is starting to run, util_probe()->vmbus_open() may have not initialized the ringbuffer yet, so thecallback can hit the panic of NULL pointer dereference.To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in__vmbus_open(), just before the first hv_ringbuffer_init(), and then weunload and reload the driver hv_utils, and run the daemon manually withinthe 10 seconds.Fix the panic by reordering the steps in util_probe() so the char deventry used by the KVP or VSS daemon is not created until aftervmbus_open() has completed. This reordering prevents the race conditionfrom happening.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:leds: class: Protect brightness_show() with led_cdev->led_access mutexThere is NULL pointer issue observed if from Process A where hid devicebeing added which results in adding a led_cdev addition and later aanother call to access of led_cdev attribute from Process B can resultin NULL pointer issue.Use mutex led_cdev->led_access to protect access to led->cdev and itsattribute inside brightness_show() and max_brightness_show() and alsoupdate the comment for mutex that it should be used to protect the ledclass device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 3313.874301][ T4013] Mem abort info:[ 3313.874303][ T4013] ESR = 0x0000000096000006[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits[ 3313.874307][ T4013] SET = 0, FnV = 0[ 3313.874309][ T4013] EA = 0, S1PTW = 0[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault[ 3313.874313][ T4013] Data abort info:[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000..[ 3313.874332][ T4013] Dumping ftrace buffer:[ 3313.874334][ T4013] (ftrace buffer empty)....[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60[ 3313.874656][ T4013] sp : ffffffc0b910bbd0....[ 3313.874685][ T4013] Call trace:[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74[ 3313.874690][ T4013] brightness_show+0x20/0x4c[ 3313.874692][ T4013] dev_attr_show+0x38/0x74[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8[ 3313.874711][ T4013] ksys_read+0x78/0xe8[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c[ 3313.874718][ T4013] invoke_syscall+0x58/0x114[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28[ 3313.874727][ T4013] el0_svc+0x38/0x68[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Hold module reference while requesting a moduleUser space may unload ip_set.ko while it is itself requesting a set typebackend module, leading to a kernel crash. The race condition may beprovoked by inserting an mdelay() right after the nfnl_unlock() call.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: wl128x: Fix atomicity violation in fmc_send_cmd()Atomicity violation occurs when the fmc_send_cmd() function is executedsimultaneously with the modification of the fmdev->resp_skb value.Consider a scenario where, after passing the validity check within thefunction, a non-null fmdev->resp_skb variable is assigned a null value.This results in an invalid fmdev->resp_skb variable passing the validitycheck. As seen in the later part of the function, skb = fmdev->resp_skb;when the invalid fmdev->resp_skb passes the check, a null pointerdereference error may occur at line 478, evt_hdr = (void *)skb->data;To address this issue, it is recommended to include the validity check offmdev->resp_skb within the locked section of the function. Thismodification ensures that the value of fmdev->resp_skb does not changeduring the validation process, thereby maintaining its validity.This possible bug is found by an experimental static analysis tooldeveloped by our team. This tool analyzes the locking APIsto extract function pairs that can be concurrently executed, and thenanalyzes the instructions in the paired functions to identify possibleconcurrency bugs including data races and atomicity violations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 > 0-0 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: make get_first_thin use rcu-safe list first functionThe documentation in rculist.h explains the absence of list_empty_rcu()and cautions programmers against relying on a list_empty() ->list_first() sequence in RCU safe code. This is because each of thesefunctions performs its own READ_ONCE() of the list head. This can leadto a situation where the list_empty() sees a valid list entry, but thesubsequent list_first() sees a different view of list head state after amodification.In the case of dm-thin, this author had a production box crash from a GPfault in the process_deferred_bios path. This function saw a valid listhead in get_first_thin() but when it subsequently dereferenced that andturned it into a thin_c, it got the inside of the struct pool, since thelist was now empty and referring to itself. The kernel on which thisoccurred printed both a warning about a refcount_t being saturated, anda UBSAN error for an out-of-bounds cpuid access in the queued spinlock,prior to the fault itself. When the resulting kdump was examined, itwas possible to see another thread patiently waiting in thin_dtr'ssynchronize_rcu.The thin_dtr call managed to pull the thin_c out of the active thinslist (and have it be the last entry in the active_thins list) at justthe wrong moment which lead to this crash.Fortunately, the fix here is straight forward. Switch get_first_thin()function to use list_first_or_null_rcu() which performs just a singleREAD_ONCE() and returns NULL if the list is already empty.This was run against the devicemapper test suite's thin-provisioningsuites for delete and suspend and no regressions were observed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: always recalculate features after XDP clearing, fix null-derefRecalculate features when XDP is detached.Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: onThe fact that HW-GRO doesn't get re-enabled automatically is justa minor annoyance. The real issue is that the features will randomlycome back during another reconfiguration which just happens to invokenetdev_update_features(). The driver doesn't handle reconfiguringtwo things at a time very robustly.Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") we only reconfigure the RSS hash tableif the "effective" number of Rx rings has changed. If HW-GRO isenabled "effective" number of rings is 2x what user sees.So if we are in the bad state, with HW-GRO re-enablement "pending"after XDP off, and we lower the rings by / 2 - the HW-GRO ringsdoing 2x and the ethtool -L doing / 2 may cancel each other out,and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings &&condition in __bnxt_reserve_rings() will be false.The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0As we try to access a freed ring.The issue is present since XDP support was added, really, butprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") it wasn't causing major issues.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: streamzap: fix race between device disconnection and urb callbackSyzkaller has reported a general protection fault at functionir_raw_event_store_with_filter(). This crash is caused by a NULL pointerdereference of dev->raw pointer, even though it is checked for NULL inthe same function, which means there is a race condition. It occurs dueto the incorrect order of actions in the streamzap_disconnect() function:rc_unregister_device() is called before usb_kill_urb(). The dev->rawpointer is freed and set to NULL in rc_unregister_device(), and onlyafter that usb_kill_urb() waits for in-progress requests to finish.If rc_unregister_device() is called while streamzap_callback() handler isnot finished, this can lead to accessing freed resources. Thusrc_unregister_device() should be called after usb_kill_urb().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: harden block_group::bg_list against list_del() racesAs far as I can tell, these calls of list_del_init() on bg_list cannotrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),as they are in transaction error paths and situations where the blockgroup is readonly.However, if there is any chance at all of racing with mark_bg_unused(),or a different future user of bg_list, better to be safe than sorry.Otherwise we risk the following interleaving (bg_list refcount in parens)T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1)list_del_init(&bg->bg_list); (1) list_move_tail (1)btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1)Ultimately, this results in a broken ref count that hits zero one derefearly and the real final deref underflows the refcount, resulting in a WARNING.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: inftlcore: Add error check for inftl_read_oob()In INFTL_findwriteunit(), the return value of inftl_read_oob()need to be checked. A proper implementation can befound in INFTL_deleteblock(). The status will be set asSECTOR_IGNORE to break from the while-loop correctlyif the inftl_read_oob() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-bufio: don't schedule in atomic contextA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP andtry_verify_in_tasklet are enabled.[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4[ 129.444740][ T934] preempt_count: 201, expected: 0[ 129.444756][ T934] RCU nest depth: 0, expected: 0[ 129.444781][ T934] Preemption disabled at:[ 129.444789][ T934] [] shrink_work+0x21c/0x248[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16![ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug][ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c[ 129.447451][ T934] sp : ffffffc0843dbc90[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000[ 129.447647][ T934] Call trace:[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6][ 129.447681][ T934] __might_resched+0x190/0x1a8[ 129.447694][ T934] shrink_work+0x180/0x248[ 129.447706][ T934] process_one_work+0x260/0x624[ 129.447718][ T934] worker_thread+0x28c/0x454[ 129.447729][ T934] kthread+0x118/0x158[ 129.447742][ T934] ret_from_fork+0x10/0x20[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---dm_bufio_lock will call spin_lock_bh when try_verify_in_taskletis enabled, and __scan will be called in atomic context.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notifyDuring our test, it is found that a warning can be trigger in try_grab_folioas follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---Digging into the source, context->notify_page may init by get_user_pages_fastand can be seen in vmci_ctx_unset_notify which will try to put_page. Howeverget_user_pages_fast is not finished here and lead to followingtry_grab_folio warning. The race condition is shown as follow:cpu0 cpu1vmci_host_do_set_notifyvmci_host_setup_notifyget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);lockless_pages_from_mmgup_pgd_rangegup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed__gup_longterm_locked__get_user_pagesfollow_trans_huge_pmdtry_grab_folio // warn hereTo slove this, use local variable page to make notify_page can be seenafter finish get_user_pages_fast.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Kill timer properly at removalThe USB-audio MIDI code initializes the timer, but in a rare case, thedriver might be freed without the disconnect call. This leaves thetimer in an active state while the assigned object is released viasnd_usbmidi_free(), which ends up with a kernel warning when the debugconfiguration is enabled, as spotted by fuzzer.For avoiding the problem, put timer_shutdown_sync() atsnd_usbmidi_free(), so that the timer can be killed properly.While we're at it, replace the existing timer_delete_sync() at thedisconnect callback with timer_shutdown_sync(), too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: red: fix a race in __red_change()Gerrard Tai reported a race condition in RED, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix TOCTOU issue in sk_is_readable()sk->sk_prot->sock_is_readable is a valid function pointer when sk residesin a sockmap. After the last sk_psock_put() (which usually happens whensocket is removed from sockmap), sk->sk_prot gets restored andsk->sk_prot->sock_is_readable becomes NULL.This makes sk_is_readable() racy, if the value of sk->sk_prot is reloadedafter the initial check. Which in turn may lead to a null pointerdereference.Ensure the function pointer does not turn NULL after the check.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring timestampingThe stmmac platform drivers that do not open-code the clk_ptp_rate valueafter having retrieved the default one from the device-tree can end upwith 0 in clk_ptp_rate (as clk_get_rate can return 0). It willeventually propagate up to PTP initialization when bringing up theinterface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)Prevent this division by 0 by adding an explicit check and error logabout the actual issue. While at it, remove the same check fromstmmac_ptp_register, which then becomes duplicate
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Do not double dequeue a configuration requestSome of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30The circumstances are unclear, however, the theory is thattb_cfg_request_work() can be scheduled twice for a request:first time via frame.callback from ring_work() and secondtime from tb_cfg_request(). Both times kworkers will executetb_cfg_request_dequeue(), which results in double list_del()from the ctl->request_queue (the list poison deference hintsat it: 0xdead000000000122).Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVEbit set.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.16.0-rc3-build2+ #1301 Tainted: G S W------------------------------------------------------cifsd/6055 is trying to acquire lock:ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30other info that might help us debug this:Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK ***3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().syzbot reported a warning below during atm_dev_register(). [0]Before creating a new device and procfs/sysfs for it, atm_dev_register()looks up a duplicated device by __atm_dev_lookup(). These operations aredone under atm_dev_mutex.However, when removing a device in atm_dev_deregister(), it releases themutex just after removing the device from the list that __atm_dev_lookup()iterates over.So, there will be a small race window where the device does not exist onthe device list but procfs/sysfs are still not removed, triggering thesplat.Let's hold the mutex until procfs/sysfs are removed inatm_dev_deregister().[0]:proc_dir_entry 'atm/atmtcp:0' already registeredWARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377Modules linked in:CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/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:0x7f38b3b74459Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0acR13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix use-after-free in vhci_flush()syzbot reported use-after-free in vhci_flush() without repro. [0]From the splat, a thread close()d a vhci file descriptor whileits device was being used by iotcl() on another thread.Once the last fd refcnt is released, vhci_release() callshci_unregister_dev(), hci_free_dev(), and kfree() for structvhci_data, which is set to hci_dev->dev->driver_data.The problem is that there is no synchronisation after unlinkinghdev from hci_dev_list in hci_unregister_dev(). There might beanother thread still accessing the hdev which was fetched beforethe unlink operation.We can use SRCU for such synchronisation.Let's run hci_dev_reset() under SRCU and wait for its completionin hci_unregister_dev().Another option would be to restore hci_dev->destruct(), which wasremoved in commit 587ae086f6e4 ("Bluetooth: Remove unusedhci-destruct cb"). However, this would not be a good solution, aswe should not run hci_unregister_dev() while there are in-flightioctl() requests, which could lead to another data-race KCSAN splat.Note that other drivers seem to have the same problem, for exmaple,virtbt_remove().[0]:BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fcf5b98e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix potential null-ptr-deref in to_atmarpd().atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clipcauses unregister hang").However, it is not enough because to_atmarpd() is called without RTNL,especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable.Also, there is no RTNL dependency around atmarpd.Let's use a private mutex and RCU to protect access to atmarpd into_atmarpd().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]l2cap_sock_resume_cb() has a similar problem that was fixed by commit1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executedunder l2cap_sock_resume_cb(), we can avoid the issue simply by checkingif chan->data is NULL.Let's not access to the killed socket in l2cap_sock_resume_cb().[0]:BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Workqueue: hci0 hci_rx_workCall trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). Forexample, the following is possible: T0 T1zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i
type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULLSince there is a small gap between checking skb queue length and skb beingunconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.In order to avoid potential NULL pointer dereference due to situations likeabove, check if skb is not NULL before passing it to zd_mac_tx_status().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Increment job count before swapping tail spsc queueA small race exists between spsc_queue_push and the run-job worker, inwhich spsc_queue_push may return not-first while the run-job worker hasalready idled due to the job count being zero. If this race occurs, jobscheduling stops, leading to hangs while waiting on the job's DMAfences.Seal this race by incrementing the job count before appending to theSPSC queue.This race was observed on a drm-tip 6.16-rc1 build with the Xe driver inan SVM test case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix memory leak of struct clip_vcc.ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it tovcc->user_back.The code assumes that vcc_destroy_socket() passes NULL skbto vcc->push() when the socket is close()d, and then clip_push()frees clip_vcc.However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() inatm_init_atmarp(), resulting in memory leak.Let's serialise two ioctl() by lock_sock() and check vcc->push()in atm_init_atmarp() to prevent memleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: fix race causing mux_owner NULL with active mux_usecountcommit 5a3e85c3c397 ("pinmux: Use sequential access to accessdesc->pinmux data") tried to address the issue when two client of thesame gpio calls pinctrl_select_state() for the same functionality, wasresulting in NULL pointer issue while accessing desc->mux_owner.However, issue was not completely fixed due to the way it was handledand it can still result in the same NULL pointer.The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux)This sequence leads to a state where the pin appears to be in use(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which cancause NULL pointer on next pin_request on the same pin.Ensure that updates to mux_usecount and mux_owner are performedatomically under the same lock. Only clear mux_owner when mux_usecountreaches zero and no new owner has been assigned.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: skbprio: Remove overly strict queue assertionsIn the current implementation, skbprio enqueue/dequeue contains an assertionthat fails under certain conditions when SKBPRIO is used as a child qdisc underTBF with specific parameters. The failure occurs because TBF sometimes peeks atpackets in the child qdisc without actually dequeuing them when tokens areunavailable.This peek operation creates a discrepancy between the parent and child qdiscqueue length counters. When TBF later receives a high-priority packet,SKBPRIO's queue length may show a different value than what's reflected in itsinternal priority queue tracking, triggering the assertion.The fix removes this overly strict assertions in SKBPRIO, they are notnecessary at all.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structureIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, theresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() mayoccur before sli4_hba.hdwqs are allocated. This may result in a nullpointer dereference when attempting to take the abts_io_buf_list_lock forthe first hardware queue. Fix by adding a null ptr check onphba->sli4_hba.hdwq and early return because this situation means theremust have been an error during port initialization.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: do not BUG when INLINE_DATA_FL lacks system.data xattrA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()when an inode had the INLINE_DATA_FL flag set but was missing thesystem.data extended attribute.Since this can happen due to a maiciouly fuzzed file system, weshouldn't BUG, but rather, report it as a corrupted file system.Add similar replacements of BUG_ON with EXT4_ERROR_INODE() iiext4_create_inline_data() and ext4_inline_data_truncate().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Check encryption key size on incoming connectionThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bitThis tests the security key with size from 1 to 15 bytes while theSecurity Mode 4 Level 4 requests 16 bytes key size.Currently PTS fails with the following logs:- expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt),but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information availableAnd HCI logs:< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)> HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7> ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64< ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix using smp_processor_id() in preemptible code warningsSyzbot reported the following warning:BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFor historical and portability reasons, the netif_rx() is usuallyrun in the softirq or interrupt context, this commit therefore addlocal_bh_disable/enable() protection in the usbnet_resume_rx().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.283.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process.A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libsystemd0 > 0-0 (version in image is 228-157.52.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Fix synchronous external abort on unbindA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind isexecuted after the configuration sequence described above:modprobe usb_f_ecmmodprobe libcompositemodprobe configfscd /sys/kernel/config/usb_gadgetmkdir -p g1cd g1echo "0x1d6b" > idVendorecho "0x0104" > idProductmkdir -p strings/0x409echo "0123456789" > strings/0x409/serialnumberecho "Renesas." > strings/0x409/manufacturerecho "Ethernet Gadget" > strings/0x409/productmkdir -p functions/ecm.usb0mkdir -p configs/c.1mkdir -p configs/c.1/strings/0x409echo "ECM" > configs/c.1/strings/0x409/configurationif [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1fiecho 11e20000.usb > UDCecho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbindThe displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1The issue occurs because usbhs_sys_function_pullup(), which accesses the IPregisters, is executed after the USBHS clocks have been disabled. Theproblem is reproducible on the Renesas RZ/G3S SoC starting with theaddition of module stop in the clock enable/disable APIs. With module stopfunctionality enabled, a bus error is expected if a master accesses amodule whose clock has been stopped and module stop activated.Disable the IP clocks at the end of remove.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_createWhen sync() and link() are called concurrently, both threads mayenter hfs_bnode_find() without finding the node in the hash tableand proceed to create it.Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it.Thread B also tries to create the same bnode, notices it has alreadybeen inserted, drops its own instance, and uses the hashed one withoutgetting the node.``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; }```However, hfs_bnode_find() requires each call to take a reference.Here both threads end up setting refcnt=1. When they later put the node,this triggers:BUG_ON(!atomic_read(&node->refcnt))In this scenario, Thread B in fact finds the node in the hash tablerather than creating a new one, and thus must take a reference.Fix this by calling hfs_bnode_get() when reusing a bnode newly created byanother thread to ensure the refcount is updated correctly.A similar bug was fixed in HFS long ago in commita9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")but the same issue remained in HFS+ until now.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: fix memory leak on usb_submit_urb() failureIn async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak. The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked. Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 > 0-0 (version in image is 0.8.7-3.9.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can'tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm->nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1("cdc-acm: reassemble fragmented notifications").A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device's vendor/product IDs andits other interfaces.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: UNIX Symbolic Link (Symlink) Following vulnerability in the cronjob shipped with nagios of SUSE Linux Enterprise Server 12, SUSE Linux Enterprise Server 11; openSUSE Factory allows local attackers to cause cause DoS or potentially escalate privileges by winning a race. This issue affects: SUSE Linux Enterprise Server 12 nagios version 3.5.1-5.27 and prior versions. SUSE Linux Enterprise Server 11 nagios version 3.0.6-1.25.36.3.1 and prior versions. openSUSE Factory nagios version 4.4.5-2.1 and prior versions.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libzmq3 < 4.0.4-15.8.1 (version in image is 4.0.4-15.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxgb4: avoid accessing registers when clearing filtersHardware register having the server TID base can containinvalid values when adapter is in bad state (for example,due to AER fatal error). Reading these invalid values in theregister can lead to out-of-bound memory access. So, fixby using the saved server TID base when clearing filters.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kcm: close race conditions on sk_receive_queuesk->sk_receive_queue is protected by skb queue lock, but for KCMsockets its RX path takes mux->rx_lock to protect more than justskb queue. However, kcm_recvmsg() still only grabs the skb queuelock, so race conditions still exist.We can teach kcm_recvmsg() to grab mux->rx_lock too but this wouldintroduce a potential performance regression as struct kcm_mux canbe shared by multiple KCM sockets.So we have to enforce skb queue lock in requeue_rx_msgs() and handleskb peek case carefully in kcm_wait_data(). Fortunately,skb_recv_datagram() already handles it nicely and is widely used byother sockets, we can just switch to skb_recv_datagram() aftergetting rid of the unnecessary sock lock in kcm_recvmsg() andkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,so it is safe to get rid of this check too.I ran the original syzbot reproducer for 30 min without seeing anyissue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: init quota for 'old.inode' in 'ext4_rename'Syzbot found the following issue:ext4_parse_param: s_want_extra_isize=128ext4_inode_info_init: s_want_extra_isize=32ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828__ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128__ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128ext4_xattr_block_set: inode=ffff88823869a2c8------------[ cut here ]------------WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980Modules linked in:RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8eR10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? ext4_xattr_set_entry+0x3b7/0x2320 ? ext4_xattr_block_set+0x0/0x2020 ? ext4_xattr_set_entry+0x0/0x2320 ? ext4_xattr_check_entries+0x77/0x310 ? ext4_xattr_ibody_set+0x23b/0x340 ext4_xattr_move_to_block+0x594/0x720 ext4_expand_extra_isize_ea+0x59a/0x10f0 __ext4_expand_extra_isize+0x278/0x3f0 __ext4_mark_inode_dirty.cold+0x347/0x410 ext4_rename+0xed3/0x174f vfs_rename+0x13a7/0x2510 do_renameat2+0x55d/0x920 __x64_sys_rename+0x7d/0xb0 do_syscall_64+0x3b/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdcAs 'ext4_rename' will modify 'old.inode' ctime and mark inode dirty,which may trigger expand 'extra_isize' and allocate block. If inodedidn't init quota will lead to warning. To solve above issue, init'old.inode' firstly in 'ext4_rename'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-mem2mem: add lock to protect parameter num_rdyGetting below error when using KCSAN to check the driver. Adding lock toprotect parameter num_rdy when getting the value with function:v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queuekworker/u16:3: [name:report&]kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: xmit: make sure we have at least eth header len bytessyzbot triggered an uninit value[1] error in bridge device's xmit pathby sending a short (less than ETH_HLEN bytes) skb. To fix it check ifwe can actually pull that amount instead of assuming.Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL[1]BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race condition in AF_XDP generic RX pathMove rx_lock from xsk_socket to xsk_buff_pool.Fix synchronization for shared umem mode ingeneric RX path where multiple sockets sharesingle xsk_buff_pool.RX queue is exclusive to xsk_socket, while FILLqueue can be shared between multiple sockets.This could result in race condition where twoCPU cores access RX path of two different socketssharing the same umem.Protect both queues by acquiring spinlock in sharedxsk_buff_pool.Lock contention may be minimized in the future by someper-thread FQ buffering.It's safe and necessary to move spin_lock_bh(rx_lock)after xsk_rcv_check():* xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers.* xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: There's a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it's possible that the program perform out of bounds write leading to a heap corruption.This issue affects only 32-bits builds of libssh.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.15.1 (version in image is 0.8.7-3.9.1).
-
Description: A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.87.1 (version in image is 2.9.4-46.65.1).
-
Description: A heap-based buffer over-read issue was discovered in the function sec_merge_hash_lookup in merge.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31, because _bfd_add_merge_section mishandles section merges when size is not a multiple of entsize. A specially crafted ELF allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:isdn: cpai: check ctr->cnr to avoid array index out of boundThe cmtp_add_connection() would add a cmtp session to a controllerand run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d", session->num);During this process, the kernel thread would call detach_capi_ctr()to detach a register controller. if the controllerwas not attached yet, detach_capi_ctr() wouldtrigger an array-index-out-bounds bug.[ 46.866069][ T6479] UBSAN: array-index-out-of-bounds indrivers/isdn/capi/kcapi.c:483:21[ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]'[ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted5.15.0-rc2+ #8[ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX,1996), BIOS 1.14.0-2 04/01/2014[ 46.870107][ T6479] Call Trace:[ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d[ 46.870974][ T6479] ubsan_epilogue+0x5/0x40[ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48[ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0[ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0[ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60[ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120[ 46.874256][ T6479] kthread+0x147/0x170[ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40[ 46.875248][ T6479] ret_from_fork+0x1f/0x30[ 46.875773][ T6479]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/xen: Drop USERGS_SYSRET64 paravirt callcommit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.USERGS_SYSRET64 is used to return from a syscall via SYSRET, buta Xen PV guest will nevertheless use the IRET hypercall, as thereis no sysret PV hypercall defined.So instead of testing all the prerequisites for doing a sysret andthen mangling the stack for Xen PV again for doing an iret just usethe iret exit from the beginning.This can easily be done via an ALTERNATIVE like it is done for thesysenter compat case already.It should be noted that this drops the optimization in Xen for notrestoring a few registers when returning to user mode, but it seemsas if the saved instructions in the kernel more than compensate forthis drop (a kernel build in a Xen PV guest was slightly faster withthis patch applied).While at it remove the stale sysret32 remnants. [ pawan: Brad Spengler and Salvatore Bonaccorso reported a problem with the 5.10 backport commit edc702b4a820 ("x86/entry_64: Add VERW just before userspace transition"). When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in syscall_return_via_sysret path as USERGS_SYSRET64 is runtime patched to: .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8, 0x48, 0x0f, 0x07 }, // swapgs; sysretq which is missing CLEAR_CPU_BUFFERS. It turns out dropping USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS to be explicitly added to syscall_return_via_sysret path. Below is with CONFIG_PARAVIRT_XXL=y and this patch applied: syscall_return_via_sysret: ... <+342>: swapgs <+345>: xchg %ax,%ax <+347>: verw -0x1a2(%rip) <------ <+354>: sysretq ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/qrwlock: Fix ordering in queued_write_lock_slowpath()While this code is executed with the wait_lock held, a reader canacquire the lock without holding wait_lock. The writer side loopschecking the value with the atomic_cond_read_acquire(), but only trulyacquires the lock when the compare-and-exchange is completedsuccessfully which isn't ordered. This exposes the window between theacquire and the cmpxchg to an A-B-A problem which allows readsfollowing the lock acquisition to observe values speculatively beforethe write lock is truly acquired.We've seen a problem in epoll where the reader does a xchg whileholding the read lock, but the writer can see a value change out fromunder it. Writer | Reader -------------------------------------------------------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->lock, flags); --> (observes value before unlock) | chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); |A core can order the read of the ovflist ahead of theatomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquiresemantics addresses this issue at which point the atomic_cond_read canbe switched to use relaxed semantics.[peterz: use try_cmpxchg()]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.ffs_data_clear is indirectly called from both ffs_fs_kill_sb andffs_ep0_release, so it ends up being called twice when userland closes ep0and then unmounts f_fs.If userland provided an eventfd along with function's USB descriptors, itends up calling eventfd_ctx_put as many times, causing a refcountunderflow.NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.Also, set epfiles to NULL right after de-allocating it, for readability.For completeness, ffs_data_clear actually ends up being called thrice, thelast call being before the whole ffs structure gets freed, so when thisspecific sequence happens there is a second underflow happening (but notbeing reported):/sys/kernel/debug/tracing# modprobe usb_f_fs/sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter/sys/kernel/debug/tracing# echo function > current_tracer/sys/kernel/debug/tracing# echo 1 > tracing_on(setup gadget, run and kill function userland process, teardown gadget)/sys/kernel/debug/tracing# echo 0 > tracing_on/sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_putWarning output corresponding to above trace:[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c[ 1946.293094] refcount_t: underflow; use-after-free.[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E)[ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1[ 1946.417950] Hardware name: BCM2835[ 1946.425442] Backtrace:[ 1946.432048] [] (dump_backtrace) from [] (show_stack+0x20/0x24)[ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c[ 1946.458412] [] (show_stack) from [] (dump_stack+0x28/0x30)[ 1946.470380] [] (dump_stack) from [] (__warn+0xe8/0x154)[ 1946.482067] r5:c04a948c r4:c0a71dc8[ 1946.490184] [] (__warn) from [] (warn_slowpath_fmt+0xa0/0xe4)[ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04[ 1946.517070] [] (warn_slowpath_fmt) from [] (refcount_warn_saturate+0x110/0x15c)[ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0[ 1946.546708] [] (refcount_warn_saturate) from [] (eventfd_ctx_put+0x48/0x74)[ 1946.564476] [] (eventfd_ctx_put) from [] (ffs_data_clear+0xd0/0x118 [usb_f_fs])[ 1946.582664] r5:c3b84c00 r4:c2695b00[ 1946.590668] [] (ffs_data_clear [usb_f_fs]) from [] (ffs_data_closed+0x9c/0x150 [usb_f_fs])[ 1946.609608] r5:bf54d014 r4:c2695b00[ 1946.617522] [] (ffs_data_closed [usb_f_fs]) from [] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs])[ 1946.636217] r7:c0dfcb---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Reserve extra IRQ vectorsCommit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number ofCPUs") lowers the number of allocated MSI-X vectors to the number of CPUs.That breaks vector allocation assumptions in qla83xx_iospace_config(),qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functionscomputes maximum number of qpairs as: ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default response queue) - 1 (ATIO, in dual or pure target mode)max_qpairs is set to zero in case of two CPUs and initiator mode. Thenumber is then used to allocate ha->queue_pair_map insideqla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map isleft NULL but the driver thinks there are queue pairs available.qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30The driver should allocate enough vectors to provide every CPU it's own HWqueue and still handle reserved (MB, RSP, ATIO) interrupts.The change fixes the crash on dual core VM and prevents unbalanced QPallocation where nr_hw_queues is two less than the number of CPUs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s: Fix pte update for kernel memory on radixWhen adding a PTE a ptesync is needed to order the update of the PTEwith subsequent accesses otherwise a spurious fault may be raised.radix__set_pte_at() does not do this for performance gains. Fornon-kernel memory this is not an issue as any faults of this kind arecorrected by the page fault handler. For kernel memory these faultsare not handled. The current solution is that there is a ptesync inflush_cache_vmap() which should be called when mapping from thevmalloc region.However, map_kernel_page() does not call flush_cache_vmap(). This istroublesome in particular for code patching with Strict RWX on radix.In do_patch_instruction() the page frame that contains the instructionto be patched is mapped and then immediately patched. With no orderingor synchronization between setting up the PTE and writing to the pageit is possible for faults.As the code patching is done using __put_user_asm_goto() the resultingfault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) &Turning ftrace on and off does a large amount of code patching whichin usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call T---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: require write permissions for locking and badblock ioctlsMEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus requirewrite permission. Depending on the hardware MEMLOCK might even bewrite-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCKis always write-once.MEMSETBADBLOCK modifies the bad block table.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler moduleHi,When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,the system crashed.The log as follows:[ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a[ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0[ 141.087464] Oops: 0010 [#1] SMP NOPTI[ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47[ 141.088009] Workqueue: events 0xffffffffc09b3a40[ 141.088009] RIP: 0010:0xffffffffc09b3a5a[ 141.088009] Code: Bad RIP value.[ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246[ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000[ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246[ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1[ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700[ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8[ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000[ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0[ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 141.088009] PKRU: 55555554[ 141.088009] Call Trace:[ 141.088009] ? process_one_work+0x195/0x390[ 141.088009] ? worker_thread+0x30/0x390[ 141.088009] ? process_one_work+0x390/0x390[ 141.088009] ? kthread+0x10d/0x130[ 141.088009] ? kthread_flush_work_fn+0x10/0x10[ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a[ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0[ 200.223464] Oops: 0010 [#1] SMP NOPTI[ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46[ 200.224008] Workqueue: events 0xffffffffc0b28a40[ 200.224008] RIP: 0010:0xffffffffc0b28a5a[ 200.224008] Code: Bad RIP value.[ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246[ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000[ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246[ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5[ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700[ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8[ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000[ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0[ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 200.224008] PKRU: 55555554[ 200.224008] Call Trace:[ 200.224008] ? process_one_work+0x195/0x390[ 200.224008] ? worker_thread+0x30/0x390[ 200.224008] ? process_one_work+0x390/0x390[ 200.224008] ? kthread+0x10d/0x130[ 200.224008] ? kthread_flush_work_fn+0x10/0x10[ 200.224008] ? ret_from_fork+0x35/0x40[ 200.224008] kernel fault(0x1) notification starting on CPU 63[ 200.224008] kernel fault(0x1) notification finished on CPU 63[ 200.224008] CR2: ffffffffc0b28a5a[ 200.224008] ---[ end trace c82a412d93f57412 ]---The reason is as follows:T1: rmmod ipmi_si. ->ipmi_unregister_smi() -> ipmi_bmc_unregister() -> __ipmi_bmc_unregister() -> kref_put(&bmc->usecount, cleanup_bmc_device); -> schedule_work(&bmc->remove_work);T2: rmmod ipmi_msghandl---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()Fix an 11-year old bug in ngene_command_config_free_buf() whileaddressing the following warnings caught with -Warray-bounds:arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]The problem is that the original code is trying to copy 6 bytes ofdata into a one-byte size member _config_ of the wrong structueFW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes alegitimate compiler warning because memcpy() overruns the lengthof &com.cmd.ConfigureBuffers.config. It seems that the rightstructure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains6 more members apart from the header _hdr_. Also, the name ofthe function ngene_command_config_free_buf() suggests that the actualintention is to ConfigureFreeBuffers, instead of ConfigureBuffers(which takes place in the function ngene_command_config_buf(), above).Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERSinto new struct config, and use &com.cmd.ConfigureFreeBuffers.config asthe destination address, instead of &com.cmd.ConfigureBuffers.config,when calling memcpy().This also helps with the ongoing efforts to globally enable-Warray-bounds and get us closer to being able to tighten theFORTIFY_SOURCE routines on memcpy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-blk: Fix memory leak among suspend/resume procedureThe vblk->vqs should be freed before we call init_vqs()in virtblk_restore().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfs: fix acl memory leak of posix_acl_create()When looking into another nfs xfstests report, I found acl anddefault_acl in nfs3_proc_create() and nfs3_proc_mknod() errorpaths are possibly leaked. Fix them in advance.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: fix NULL deref in fifo_set_limit()syzbot reported another NULL deref in fifo_set_limit() [1]I could repro the issue with :unshare -ntc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbittc qd replace dev lo parent 1:0 pfifo_fasttc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbitpfifo_fast does not have a change() operation.Make fifo_set_limit() more robust about this.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0Oops: 0010 [#1] PREEMPT SMP KASANCPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:0x0Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: fifo_set_limit net/sched/sch_fifo.c:242 [inline] fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418 qdisc_change net/sched/sch_api.c:1332 [inline] tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of boundIn line 5001, if all id in the array 'lp->phy[8]' is not 0, when the'for' end, the 'k' is 8.At this time, the array 'lp->phy[8]' may be out of bound.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()Coverity reports a possible NULL dereferencing problem:in smc_vlan_by_tcpsk():6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower);CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.1624 if (is_vlan_dev(ndev)) {Remove the manual implementation and use netdev_walk_all_lower_dev() toiterate over the lower devices. While on it remove an obsolete functionparameter comment.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vt: fix memory overlapping when deleting chars in the bufferA memory overlapping copy occurs when deleting a long line. This memoryoverlapping copy can cause data corruption when scr_memcpyw is optimizedto memcpy because memcpy does not ensure its behavior if the destinationbuffer overlaps with the source buffer. The line buffer is not alwaysbroken, because the memcpy utilizes the hardware acceleration, whoseresult is not deterministic.Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix temporary data corruption in insert rangeinsert range doesn't discard the affected cached regionso can risk temporarily corrupting file data.Also includes some minor cleanup (avoiding rereadinginode size repeatedly unnecessarily) to make it clearer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix temporary data corruption in collapse rangecollapse range doesn't discard the affected cached regionso can risk temporarily corrupting the file data. Thisfixes xfstest generic/031I also decided to merge a minor cleanup to this into the same patch(avoiding rereading inode size repeatedly unnecessarily) to make itclearer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereferenceAdded checking of pointer "function" in pcs_set_mux().pinmux_generic_get_function() can return NULL and the pointer"function" was dereferenced without checking against NULL.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix list corruption in perf_cgroup_switch()There's list corruption on cgrp_cpuctx_list. This happens on thefollowing path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the listUse list_for_each_entry_safe() to allow removing an entry duringiteration.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net-sysfs: add check for netdevice being present to speed_showWhen bringing down the netdevice or system shutdown, a panic can betriggered while accessing the sysfs path because the device is alreadyremoved. [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)To prevent this scenario, we also make sure that the netdevice is present.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: Fix memory leak in dsp_pipeline_build()dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),but then it updates dup variable by strsep(&dup, "|").As a result when it calls kfree(dup), the dup variable contains NULL.Found by Linux Driver Verification project (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: fix memory corruption when tag_size is less than digest sizeIt is possible to set up dm-integrity in such a way that the"tag_size" parameter is less than the actual digest size. In thissituation, a part of the digest beyond tag_size is ignored.In this case, dm-integrity would write beyond the end of theic->recalc_tags array and corrupt memory. The corruption happened inintegrity_recalc->integrity_sector_checksum->crypto_shash_final.Fix this corruption by increasing the tags array so that it has enoughpadding at the end to accomodate the loop in integrity_recalc() beingable to write a full digest size for the last member of the tagsarray.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Fix potential crash on module unloadThe vmbus driver relies on the panic notifier infrastructure to performsome operations when a panic event is detected. Since vmbus can be builtas module, it is required that the driver handles both registering andunregistering such panic notifier callback.After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")though, the panic notifier registration is done unconditionally in the moduleinitialization routine whereas the unregistering procedure is conditionallyguarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capabilityis set.This patch fixes that by unconditionally unregistering the panic notifierin the module's exit routine as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Ignore multiple conn complete eventsWhen one of the three connection complete events is received multipletimes for the same handle, the device is registered multiple times whichleads to memory corruptions. Therefore, consequent events for a singleconnection are ignored.The conn->state can hold different values, therefore HCI_CONN_HANDLE_UNSETis introduced to identify new connections. To make sure the events do notcontain this or another invalid handle HCI_CONN_HANDLE_MAX and checksare introduced.Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Avoid out of bounds access when parsing _CPC dataIf the NumEntries field in the _CPC return package is less than 2, donot attempt to access the "Revision" element of that package, becauseit may not be present then.BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: enforce a consistent minimal mtumacvlan should enforce a minimal mtu of 68, even at link creation.This patch avoids the current behavior (which could lead to crashesin ipv6 stack if the link is brought up)$ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail !$ ip link sh dev macvlan15: macvlan1@eno1: mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff$ ip link set macvlan1 mtu 67Error: mtu less than device minimum.$ ip link set macvlan1 mtu 68$ ip link set macvlan1 mtu 8Error: mtu less than device minimum.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-transport: fix error handling in ata_tport_add()In ata_tport_add(), the return value of transport_add_device() isnot checked. As a result, it causes null-ptr-deref while removingthe module, because transport_remove_device() is called to removethe device that was not added.Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : device_del+0x48/0x39clr : device_del+0x44/0x39cCall trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci]Fix this by checking and handling return value of transport_add_device()in ata_tport_add().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix warning in 'ext4_da_release_space'Syzkaller report issue as follows:EXT4-fs (loop0): Free/Dirty block detailsEXT4-fs (loop0): free_blocks=0EXT4-fs (loop0): dirty_blocks=0EXT4-fs (loop0): Block reservation detailsEXT4-fs (loop0): i_reserved_data_blocks=0EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks------------[ cut here ]------------WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524Modules linked in:CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022Workqueue: writeback wb_workfn (flush-7:0)RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 Above issue may happens as follows:ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);__ext4_ioctl ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flagext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 allocated = true; ext4_es_insert_delayed_block(inode, lblk, allocated);ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger warning as aboveTo solve above issue, forbid inode do migrate which has inline data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspaceCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes/dev/kvm to userspace and thus allows userspace to create VMs (and callother ioctls). E.g. KVM will encounter a NULL pointer when attempting toadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able tocreate a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is deadftrace_startup does not remove ops from ftrace_ops_list whenftrace_startup_enable fails:register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1 ... return 0 // ops is in the ftrace_ops_list.When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function is not executed, // as a result, ops is still in the ftrace_ops_list __unregister_ftrace_function ...If ops is dynamically allocated, it will be free later, in this case,is_ftrace_trampoline accesses NULL pointer:is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!Syzkaller reports as follows:[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b[ 1203.508039] #PF: supervisor read access in kernel mode[ 1203.508798] #PF: error_code(0x0000) - not-present page[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008[ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000[ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Therefore, when ftrace_startup_enable fails, we need to rollback registrationprocess and remove ops from ftrace_ops_list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: verify the expected usb_endpoints are presentThe bug arises when a USB device claims to be an ATH9K but doesn'thave the expected endpoints. (In this case there was an interruptendpoint where the driver expected a bulk endpoint.) The kernelneeds to be able to handle such devices without getting an internal error.usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493Modules linked in:CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events request_firmware_work_funcRIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493Call Trace: ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sysfs: Fix attempting to call device_add multiple timesdevice_add shall not be called multiple times as stated in itsdocumentation: 'Do not call this routine or device_register() more than once for any device structure'Syzkaller reports a bug as follows [1]:------------[ cut here ]------------kernel BUG at lib/list_debug.c:33!invalid opcode: 0000 [#1] PREEMPT SMP KASAN[...]Call Trace: __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90 drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53 hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: lvds: fix PM usage counter unbalance in poweronpm_runtime_get_sync will increment pm usage counter even it failed.Forgetting to putting operation will result in reference leak here.We fix it by replacing it with the newest pm_runtime_resume_and_getto keep usage counter balanced.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash when I/O abort times outWhile performing CPU hotplug, a crash with the following stack was seen:Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0On abort timeout, completion was called without checking if the I/O wasalready completed.Verify that I/O and abort request are indeed outstanding before attemptingcompletion.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()As comment of pci_get_class() says, it returns a pci_device with itsrefcount increased and decreased the refcount for the input parameter@from if it is not NULL.If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, weneed to call pci_dev_put() to decrease the refcount. Add the missingpci_dev_put() to avoid refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix memory leak in ocfs2_mount_volume()There is a memory leak reported by kmemleak: unreferenced object 0xffff88810cc65e60 (size 32): comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s) hex dump (first 32 bytes): 10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................ 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................ backtrace: [] __kmalloc+0x4d/0x150 [] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2] [] ocfs2_check_volume+0x485/0x900 [ocfs2] [] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2] [] ocfs2_fill_super+0xe0b/0x1740 [ocfs2] [] mount_bdev+0x312/0x400 [] legacy_get_tree+0xed/0x1d0 [] vfs_get_tree+0x7d/0x230 [] path_mount+0xd62/0x1760 [] do_mount+0xca/0xe0 [] __x64_sys_mount+0x12c/0x1a0 [] do_syscall_64+0x35/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0This call stack is related to two problems. Firstly, the ocfs2 super uses"replay_map" to trace online/offline slots, in order to recover offlineslots during recovery and mount. But when ocfs2_truncate_log_init()returns an error in ocfs2_mount_volume(), the memory of "replay_map" willnot be freed in error handling path. Secondly, the memory of "replay_map"will not be freed if d_make_root() returns an error in ocfs2_fill_super().But the memory of "replay_map" will be freed normally when completingrecovery and mount in ocfs2_complete_mount_recovery().Fix the first problem by adding error handling path to free "replay_map"when ocfs2_truncate_log_init() fails. And fix the second problem bycalling ocfs2_free_replay_slots(osb) in the error handling path"out_dismount". In addition, since ocfs2_free_replay_slots() is static,it is necessary to remove its static attribute and declare it in headerfile.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ensure sane device mtu in tunnelsAnother syzbot report [1] with no reproducer hintsat a bug in ip6_gre tunnel (dev:ip6gretap0)Since ipv6 mcast code makes sure to read dev->mtu onceand applies a sanity check on it (see commit b9b312a7a451"ipv6: mcast: better catch silly mtu values"), a remainingpossibility is that a layer is able to set dev->mtu toan underflowed value (high order bit set).This could happen indeed in ip6gre_tnl_link_config_route(),ip6_tnl_link_config() and ipip6_tunnel_bind_dev()Make sure to sanitize mtu value in a local variable beforeit is written once on dev->mtu, as lockless readers couldcatch wrong temporary value.[1]skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0------------[ cut here ]------------kernel BUG at net/core/skbuff.c:120Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022Workqueue: mld mld_ifc_workpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116sp : ffff800020dd3b60x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089Call trace:skb_panic+0x4c/0x50 net/core/skbuff.c:116skb_over_panic net/core/skbuff.c:125 [inline]skb_put+0xd4/0xdc net/core/skbuff.c:2049ip6_mc_hdr net/ipv6/mcast.c:1714 [inline]mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765add_grhead net/ipv6/mcast.c:1851 [inline]add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653process_one_work+0x2d8/0x504 kernel/workqueue.c:2289worker_thread+0x340/0x610 kernel/workqueue.c:2436kthread+0x12c/0x158 kernel/kthread.c:376ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: amd - Fix PCI device refcount leakfor_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() for the normal and error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.183.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in Shim when an error happened while creating a new ESL variable. If Shim fails to create the new variable, it tries to print an error message to the user; however, the number of parameters used by the logging function doesn't match the format string used by it, leading to a crash under certain circumstances.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: An out-of-bounds read flaw was found in Shim due to the lack of proper boundary verification during the load of a PE binary. This flaw allows an attacker to load a crafted PE binary, triggering the issue and crashing Shim, resulting in a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: A flaw was found in the MZ binary format in Shim. An out-of-bounds read may occur, leading to a crash or possible exposure of sensitive data during the system's boot phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: Transmit requests in Xen's virtual network protocol can consist ofmultiple parts. While not really useful, except for the initial partany of them may be of zero length, i.e. carry no data at all. Besides acertain initial portion of the to be transferred data, these parts aredirectly translated into what Linux calls SKB fragments. Such convertedrequest parts can, when for a particular SKB they are all of lengthzero, lead to a de-reference of NULL in core networking code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: Avoid touching renamed directory if parent does not changeThe VFS will not be locking moved directory if its parent does notchange. Change ocfs2 rename code to avoid touching renamed directory ifits parent does not change as without locking that can corrupt thefilesystem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bugoccurs when txs->cnt, data from a URB provided by a USB device, isbigger than the size of the array txs->txstatus, which isHTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bughandling code after the check. Make the function return if that is thecase.Found by a modified version of syzkaller.UBSAN: array-index-out-of-bounds in htc_drv_txrx.cindex 13 is out of range for type '__wmi_event_txstatus [12]'Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rt2x00: restart beacon queue when hardware resetWhen a hardware reset is triggered, all registers are reset, so allqueues are forced to stop in hardware interface. However, mac80211will not automatically stop the queue. If we don't manually stop thebeacon queue, the queue will be deadlocked and unable to start again.This patch fixes the issue where Apple devices cannot connect to theAP after calling ieee80211_restart_hw().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix buffer overflow in trans_stat_showFix buffer overflow in trans_stat_show().Convert simple snprintf to the more secure scnprintf with size ofPAGE_SIZE.Add condition checking if we are exceeding PAGE_SIZE and exit early fromloop. Also add at the end a warning that we exceeded PAGE_SIZE and thatstats is disabled.Return -EFBIG in the case where we don't have enough space to write thefull transition table.Also document in the ABI that this function can return -EFBIG error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: core - Fix page fault dead lock on mmap-ed hwrngThere is a dead-lock in the hwrng device read path. This triggerswhen the user reads from /dev/hwrng into memory also mmap-ed from/dev/hwrng. The resulting page fault triggers a recursive readwhich then dead-locks.Fix this by using a stack buffer when calling copy_to_user.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid online resizing failures due to oversized flex bgWhen we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16Gthe following WARN_ON is triggered:==================================================================WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550Modules linked in: sg(E)CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314RIP: 0010:__alloc_pages+0x411/0x550Call Trace: __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90==================================================================This is because flexbg_size is too large and the size of the new_group_dataarray to be allocated exceeds MAX_ORDER. Currently, the minimum value ofMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the correspondingmaximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ~ 21845And the value that is down-aligned to the power of 2 is 16384. Therefore,this value is defined as MAX_RESIZE_BG, and the number of groups addedeach time does not exceed this value during resizing, and is added multipletimes to complete the online resizing. The difference is that the metadatain a flex_bg may be more dispersed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: prevent potential string overflowThe dev->id value comes from ida_alloc() so it's a number between zeroand INT_MAX. If it's too high then these sprintf()s will overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Fix uninitialized array access for some pathnamesFor filenames that begin with . and are between 2 and 5 characters long,UDF charset conversion code would read uninitialized memory in theoutput buffer. The only practical impact is that the name may be prepended a"unification hash" when it is not actually needed but still it is goodto fix this.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: check slab-out-of-bounds in md_bitmap_get_counterIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()will return -EINVAL because 'page >= bitmap->pages', but the return valuewas not checked immediately in md_bitmap_get_counter() in order to set*blocks value and slab-out-of-bounds occurs.Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() andreturn directly if true.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix deadloop issue on reading trace_pipeSoft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Through the vmcore, I found it's because in tracing_read_pipe(),ring_buffer_empty_cpu() found some buffer is not empty but then itcannot read anything due to "rb_num_of_entries() == 0" always true,Then it infinitely loop the procedure due to user buffer not beenfilled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }By some analyzing, I found that when resetting ringbuffer, the 'entries'of its pages are not all cleared (see rb_reset_cpu()). Then when reducingthe ringbuffer, and if some reduced pages exist dirty 'entries' data, theywill be added into 'cpu_buffer->overrun' (see rb_remove_pages()), whichcause wrong 'overrun' count and eventually cause the deadloop issue.To fix it, we need to clear every pages in rb_reset_cpu().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: Fix __bch_btree_node_alloc to make the failure behavior consistentIn some specific situations, the return value of __bch_btree_node_allocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.Fix it by initializing the return value in __bch_btree_node_alloc.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix one memleak in __inet_del_ifa()I got the below warning when do fuzzing test:unregister_netdevice: waiting for bond0 to become free. Usage count = 2It can be repoduced via:ip link add bond0 type bondsysctl -w net.ipv4.conf.bond0.promote_secondaries=1ip addr add 4.117.174.103/0 scope 0x40 dev bond0ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0ip addr del 4.117.174.103/0 scope 0x40 dev bond0ip link delete bond0 type bondIn this reproduction test case, an incorrect 'last_prim' is found in__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)is lost. The memory of the secondary address is leaked and the reference ofin_device and net_device is leaked.Fix this problem:Look for 'last_prim' starting at location of the deleted IP and insertingthe promoted IP into the location of 'last_prim'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Lock external INTx masking opsMask operations through config space changes to DisINTx may race INTxconfiguration changes via ioctl. Create wrappers that add locking forpaths outside of the core interrupt code.In particular, irq_type is updated holding igate, therefore testingis_intx() requires holding igate. For example clearing DisINTx fromconfig space can otherwise race changes of the interrupt configuration.This aligns interfaces which may trigger the INTx eventfd into twocamps, one side serialized by igate and the other only enabled whileINTx is configured. A subsequent patch introduces synchronization forthe latter flows.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Create persistent INTx handlerA vulnerability exists where the eventfd for INTx signaling can bedeconfigured, which unregisters the IRQ handler but still allowseventfds to be signaled with a NULL context through the SET_IRQS ioctlor through unmask irqfd if the device interrupt is pending.Ideally this could be solved with some additional locking; the igatemutex serializes the ioctl and config space accesses, and the interrupthandler is unregistered relative to the trigger, but the irqfd pathruns asynchronous to those. The igate mutex cannot be acquired from theatomic context of the eventfd wake function. Disabling the irqfdrelative to the eventfd registration is potentially incompatible withexisting userspace.As a result, the solution implemented here moves configuration of theINTx interrupt handler to track the lifetime of the INTx context objectand irq_type configuration, rather than registration of a particulartrigger eventfd. Synchronization is added between the ioctl path andeventfd_signal() wrapper such that the eventfd trigger can bedynamically updated relative to in-flight interrupts or irqfd callbacks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/platform: Create persistent IRQ handlersThe vfio-platform SET_IRQS ioctl currently allows loopback triggering ofan interrupt before a signaling eventfd has been configured by the user,which thereby allows a NULL pointer dereference.Rather than register the IRQ relative to a valid trigger, register allIRQs in a disabled state in the device open path. This allows maskoperations on the IRQ to nest within the overall enable state governedby a valid eventfd signal. This decouples @masked, protected by the@locked spinlock from @trigger, protected via the @igate mutex.In doing so, it's guaranteed that changes to @trigger cannot race theIRQ handlers because the IRQ handler is synchronously disabled beforemodifying the trigger, and loopback triggering of the IRQ via ioctl issafe due to serialization with trigger changes via igate.For compatibility, request_irq() failures are maintained to be local tothe SET_IRQS ioctl rather than a fatal error in the open device path.This allows, for example, a userspace driver with polling mode supportto continue to work regardless of moving the request_irq() call site.This necessarily blocks all SET_IRQS access to the failed index.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: do not wait in vain when unloading moduleThe module exit path has race between deleting all controllers andfreeing 'left over IDs'. To prevent double free a synchronizationbetween nvme_delete_ctrl and ida_destroy has been added by the initialcommit.There is some logic around trying to prevent from hanging forever inwait_for_completion, though it does not handling all cases. E.g.blktests is able to reproduce the situation where the module unloadhangs forever.If we completely rely on the cleanup code executed from thenvme_delete_ctrl path, all IDs will be freed eventually. This makescalling ida_destroy unnecessary. We only have to ensure that allnvme_delete_ctrl code has been executed before we leavenvme_fc_exit_module. This is done by flushing the nvme_delete_wqworkqueue.While at it, remove the unused nvme_fc_wq workqueue too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: sysfs: Fix reference leak in sysfs_break_active_protection()The sysfs_break_active_protection() routine has an obvious referenceleak in its error path. If the call to kernfs_find_and_get() fails thenkn will be NULL, so the companion sysfs_unbreak_active_protection()routine won't get called (and would only cause an access violation bytrying to dereference kn->parent if it was called). As a result, thereference to kobj acquired at the start of the function will never bereleased.Fix the leak by adding an explicit kobject_put() call when kn is NULL.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Disable auto-enable of exclusive INTx IRQCurrently for devices requiring masking at the irqchip for INTx, ie.devices without DisINTx support, the IRQ is enabled in request_irq()and subsequently disabled as necessary to align with the masked statusflag. This presents a window where the interrupt could fire betweenthese events, resulting in the IRQ incrementing the disable depth twice.This would be unrecoverable for a user since the masked flag preventsnested enables through vfio.Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTxis never auto-enabled, then unmask as required.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3-urllib3 < 1.25.10-3.40.1 (version in image is 1.25.10-3.34.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix UAF for cq async eventThe refcount of CQ is not protected by locks. When CQ asynchronousevents and CQ destruction are concurrent, CQ may have been released,which will cause UAF.Use the xa_lock() to protect the CQ refcount.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: vc4: Fix possible null pointer dereferenceIn vc4_hdmi_audio_init() of_get_address() may returnNULL which is later dereferenced. Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binariesThe allocation failure of mycs->yuv_scaler_binary in load_video_binaries()is followed with a dereference of mycs->yuv_scaler_binary after thefollowing call chain:sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()In unload_video_binaries(), it calls to ia_css_binary_unload with argument&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to thesame memory slot as mycs->yuv_scaler_binary. Thus, a null-pointerdereference is triggered.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix overwriting ct original tuple for ICMPv6OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structurewith the metadata like conntrack state, input port, recirculation id,etc. Then the packet itself gets parsed to populate the rest of thekeys from the packet headers.Whenever the packet parsing code starts parsing the ICMPv6 header, itfirst zeroes out fields in the key corresponding to Neighbor Discoveryinformation even if it is not an ND packet.It is an 'ipv6.nd' field. However, the 'ipv6' is a union that sharesthe space between 'nd' and 'ct_orig' that holds the original tupleconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.ND packets should not normally have conntrack state, so it's fine toshare the space, but normal ICMPv6 Echo packets or maybe other types ofICMPv6 can have the state attached and it should not be overwritten.The issue results in all but the last 4 bytes of the destinationaddress being wiped from the original conntrack tuple leading toincorrect packet matching and potentially executing wrong actionsin case this packet recirculates within the datapath or goes backto userspace.ND fields should not be accessed in non-ND packets, so not clearingthem should be fine. Executing memset() only for actual ND packets toavoid the issue.Initializing the whole thing before parsing is needed because ND packetmay not contain all the options.The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn'taffect packets entering OVS datapath from network interfaces, becausein this case CT metadata is populated from skb after the packet isalready parsed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:epoll: be better about file lifetimesepoll can call out to vfs_poll() with a file pointer that may race withthe last 'fput()'. That would make f_count go down to zero, and whilethe ep->mtx locking means that the resulting file pointer tear-down willbe blocked until the poll returns, it means that f_count is alreadydead, and any use of it won't actually get a reference to the file anymore: it's dead regardless.Make sure we have a valid ref on the file pointer before we call down tovfs_poll() from the epoll routines.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:eth: sungem: remove .ndo_poll_controller to avoid deadlocksErhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20cgem_poll_controller() disables interrupts, which may sleep.We can't sleep in netpoll, it has interrupts disabled completely.Strangely, gem_poll_controller() doesn't even poll the completions,and instead acts as if an interrupt has fired so it just schedulesNAPI and exits. None of this has been necessary for years, sincenetpoll invokes NAPI directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix resync softlockup when bitmap size is less than array sizeIs is reported that for dm-raid10, lvextend + lvchange --syncaction willtrigger following softlockup:kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1RIP: 0010:_raw_spin_unlock_irq+0x13/0x30Call Trace: md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30And the detailed process is as follows:md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never changeRoot cause is that commit 301867b1c168 ("md/raid10: checkslab-out-of-bounds in md_bitmap_get_counter") return early frommd_bitmap_get_counter(), without setting returned blocks.Fix this problem by always set returned blocks frommd_bitmap_get_counter"(), as it used to be.Noted that this patch just fix the softlockup problem in kernel, thecase that bitmap size doesn't match array size still need to be fixed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix netif state handlingmlx5e_suspend cleans resources only if netif_device_present() returnstrue. However, mlx5e_resume changes the state of netif, viamlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.In the below case, the above leads to NULL-ptr Oops[1] and memoryleaks:mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason.ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :(Hence, clean resources in this case as well.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at0xffffffffffffffd6.RSP: 0018:ffff888178aaf758 EFLAGS: 00010246Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? asm_exc_page_fault+0x22/0x30 notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] probe_one+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+0xbf/0x210 ? kernfs_create_link+0x5d/0xa0 ? sysfs_do_create_link_sd+0x60/0xc0 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don't intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos/vidi: fix memory leak in .get_modes()The duplicated EDID is never freed. Fix it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix crash while reading debugfs attributeThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directlyon a __user pointer, which results into the crash.To fix this issue, use a small local stack buffer for sprintf() and thencall simple_read_from_buffer(), which in turns make the copy_to_user()call.BUG: unable to handle page fault for address: 00007f4801111000PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0Oops: 0002 [#1] PREEMPT SMP PTIHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023RIP: 0010:memcpy_orig+0xcd/0x130RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000fRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fffR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7afFS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7f4800f20b4d
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prefer nft_chain_validatenft_chain_validate already performs loop detection because a cycle willresult in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).It also follows maps via ->validate callback in nft_lookup, so thereappears no reason to iterate the maps again.nf_tables_check_loops() and all its helper functions can be removed.This improves ruleset load time significantly, from 23s down to 12s.This also fixes a crash bug. Old loop detection code can result inunbounded recursion:BUG: TASK stack guard page was hit at ....Oops: stack guard page: 0000 [#1] PREEMPT SMP KASANCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1[..]with a suitable ruleset during validation of register stores.I can't see any actual reason to attempt to check for this fromnft_validate_register_store(), at this point the transaction is still inprogress, so we don't have a full picture of the rule graph.For nf-next it might make sense to either remove it or make this dependon table->validate_state in case we could catch an error earlier(for improved error reporting to userspace).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: wext: add extra SIOCSIWSCAN data checkIn 'cfg80211_wext_siwscan()', add extra check whether number ofchannels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceedIW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: validate nvme_local_port correctlyThe driver load failed with error message,qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffefand with a kernel crash, BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx]Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()fails and correctly validate nvme_local_port.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end ofa line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer atthe specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Mark XDomain as unplugged when router is removedI noticed that when we do discrete host router NVM upgrade and it getshot-removed from the PCIe side as a result of NVM firmware authentication,if there is another host connected with enabled paths we hang in tearingthem down. This is due to fact that the Thunderbolt networking driveralso tries to cleanup the paths and ends up blocking intb_disconnect_xdomain_paths() waiting for the domain lock.However, at this point we already cleaned the paths in tb_stop() sothere is really no need for tb_disconnect_xdomain_paths() to do thatanymore. Furthermore it already checks if the XDomain is unplugged andbails out early so take advantage of that and mark the XDomain asunplugged when we remove the parent router.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:of/irq: Prevent device address out-of-bounds read in interrupt map walkWhen of_irq_parse_raw() is invoked with a device address smaller thanthe interrupt parent node (from #address-cells property), KASAN detectsthe following out-of-bounds read when populating the initial match table(dyndbg="func of_irq_parse_* +p"): OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764 CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ... The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680) The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it !Prevent the out-of-bounds read by copying the device address into abuffer of sufficient size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: Guard against bad data for ATIF ACPI methodIf a BIOS provides bad data in response to an ATIF method callthis causes a NULL pointer dereference in the caller.```? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)? exc_page_fault (arch/x86/mm/fault.c:1542)? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu```It has been encountered on at least one system, so guard for it.(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:initramfs: avoid filename buffer overrunThe initramfs filename field is defined inDocumentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== =========================... 70 c_namesize 8 bytes Length of filename, including final \0When extracting an initramfs cpio archive, the kernel's do_name() pathhandler assumes a zero-terminated path at @collected, passing itdirectly to filp_open() / init_mkdir() / init_mknod().If a specially crafted cpio entry carries a non-zero-terminated filenameand is followed by uninitialized memory, then a file may be created withtrailing characters that represent the uninitialized memory. The abilityto create an initramfs entry would imply already having full control ofthe system, so the buffer overrun shouldn't be considered a securityvulnerability.Append the output of the following bash script to an existing initramfsand observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfsIt's easiest to observe non-zero uninitialized memory when the output isgzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),rather than the initrd_start+initrd_size block.---- reproducer.sh ----nilchar="A" # change to "\0" to properly zero terminate / padmagic="070701"ino=1mode=$(( 0100777 ))uid=0gid=0nlink=1mtime=1filesize=0devmajor=0devminor=1rdevmajor=0rdevminor=0csum=0fname="initramfs_test_fname_overrun"namelen=$(( ${#fname} + 1 )) # plus one to account for terminatorprintf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fnametermpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))printf "%.s${nilchar}" $(seq 1 $termpadlen)---- reproducer.sh ----Symlink filename fields handled in do_symlink() won't overrun past thedata segment, due to the explicit zero-termination of the symlinktarget.Fix filename buffer overrun by aborting the initramfs FSM if any cpioentry doesn't carry a zero-terminator at the expected (name_len - 1)offset.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix regression with module command in stack_trace_filterWhen executing the following command: # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filterThe current mod command causes a null pointer dereference. While commit0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter")has addressed part of the issue, it left a corner case unhandled, which stillresults in a kernel crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: ts2020: fix null-ptr-deref in ts2020_probe()KASAN reported a null-ptr-deref issue when executing the followingcommand: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...The cause of the problem is that when using sysfs to dynamically registeran i2c device, there is no platform data, but the probe process of ts2020needs to use platform data, resulting in a null pointer being accessed.Solve this problem by adding checks to platform data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: avoid NULL pointer error during sdio removeWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdioworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ONis set to yes, kernel panic will happen:Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2cThis is because during 'rmmod ath10k', ath10k_sdio_remove() will callath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()will finally be called in ath10k_core_destroy(). This function will freestruct cfg80211_registered_device *rdev and all its members, includingwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdioworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.After device release, destroy_workqueue() will use NULL pointer then thekernel panic happen.Call trace:ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueueNeed to call destroy_workqueue() before ath10k_core_destroy(), freethe work queue buffer first and then free pointer of work queue byath10k_core_destroy(). This order matches the error path order inath10k_sdio_probe().No work will be queued on sdio workqueue between it is destroyed andath10k_core_destroy() is called. Based on the call_stack above, thereason is:Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() andath10k_sdio_irq_disable() will queue work on sdio workqueue.Sleep timer will be deleted before ath10k_core_destroy() inath10k_hif_power_down().ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().ath10k_core_unregister() will call ath10k_hif_power_down() to stop hifbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in grub2. Grub's dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla1280: Fix kernel oops when debug level > 2A null dereference or oops exception will eventually occur when qla1280.cdriver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. Ithink its clear from the code that the intention here is sg_dma_len(s) notlength of sg_next(s) when printing the debug info.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libgnutls30 > 0-0 (version in image is 3.4.17-8.14.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix oob write in trace_seq_to_buffer()syzbot reported this bug:==================================================================BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 ....==================================================================It has been reported that trace_seq_to_buffer() tries to copy more datathan PAGE_SIZE to buf. Therefore, to prevent this, we should use thesmaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihidThere is a string parsing logic error which can lead to an overflow of hidor uid buffers. Comparing ACPIID_LEN against a total string length doesn'ttake into account the lengths of individual hid and uid buffers so thecheck is insufficient in some cases. For example if the length of hidstring is 4 and the length of the uid string is 260, the length of strwill be equal to ACPIID_LEN + 1 but uid string will overflow uid bufferwhich size is 256.The same applies to the hid string with length 13 and uid string withlength 250.Check the length of hid and uid strings separately to preventbuffer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: correct the order of prelim_ref arguments in btrfs__prelim_refbtrfs_prelim_ref() calls the old and new reference variables in theincorrect order. This causes a NULL pointer dereference because oldrefis passed as NULL to trace_btrfs_prelim_ref_insert().Note, trace_btrfs_prelim_ref_insert() is being called with newref asoldref (and oldref as NULL) on purpose in order to print outthe values of newref.To reproduce:echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enablePerform some writeback operations.Backtrace:BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: aqc111: fix error handling of usbnet read callsSyzkaller, courtesy of syzbot, identified an error (see report [1]) inaqc111 driver, caused by incomplete sanitation of usb read calls'results. This problem is quite similar to the one fixed in commit920a9fa27e78 ("net: asix: add proper error handling of usb read errors").For instance, usbnet_read_cmd() may read fewer than 'size' bytes,even if the caller expected the full amount, and aqc111_read_cmd()will not check its result properly. As [1] shows, this may leadto MAC address in aqc111_bind() being only partly initialized,triggering KMSAN warnings.Fix the issue by verifying that the number of bytes read isas expected and not less.[1] Partial syzbot report:BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline]BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800...Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396...Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline]...Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================Even though fbcon_init() checks beforehand if fb_match_mode() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It'sthen passed to fb_cvt_hperiod(), where it's used as a divider -- divisionby 0 will result in kernel oops. Add a sanity check for cvt.f_refresh toavoid such overflow...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Destroy KFD debugfs after destroy KFD wqSince KFD proc content was moved to kernel debugfs, we can't destroy KFDdebugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq priorto kfd_debugfs_fini to fix a kernel NULL pointer problem. It happenswhen /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini butkfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry);tries to remove /sys/kernel/debug/kfd/proc/
while/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernelNULL pointer.(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not allow relocation of partially dropped subvolumes[BUG]There is an internal report that balance triggered transaction abort,with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]And btrfs check doesn't report anything wrong related to the extenttree.[CAUSE]The cause is a little complex, firstly the extent tree indeed doesn'thave the backref for 594526208.The extent tree only have the following two backrefs around that bytenron-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREEBut the such missing backref item is not an corruption on disk, as theoffending delayed ref belongs to subvolume 934, and that subvolume isbeing dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229And that offending tree block 594526208 is inside the dropped range ofthat subvolume. That explains why there is no backref item for thatbytenr and why btrfs check is not reporting anything wrong.But this also shows another problem, as btrfs will do all the orphansubvolume cleanup at a read-write mount.So half-dropped subvolume should not exist after an RW mount, andbalance itself is also exclusive to subvolume cleanup, meaning weshouldn't hit a subvolume half-dropped during relocation.The root cause is, there is no orphan item for this subvolume.In fact there are 5 subvolumes from around 2021 that have the sameproblem.It looks like the original report has some older kernels running, andcaused those zombie subvolumes.Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshotdeletion not triggered on mount") has long fixed the bug.[ENHANCEMENT]For repairing such old fs, btrfs-progs will be enhanced.Considering how delayed the problem will show up (at run delayed reftime) and at that time we have to abort transaction already, it is toolate.Instead here we reject any half-dropped subvolume for reloc tree at theearliest time, preventing confusion and extra time wasted on debuggingsimilar bugs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: APEI: send SIGBUS to current task if synchronous memory error not recoveredIf a synchronous error is detected as a result of user-space processtriggering a 2-bit uncorrected error, the CPU will take a synchronouserror exception such as Synchronous External Abort (SEA) on Arm64. Thekernel will queue a memory_failure() work which poisons the relatedpage, unmaps the page, and then sends a SIGBUS to the process, so thata system wide panic can be avoided.However, no memory_failure() work will be queued when abnormalsynchronous errors occur. These errors can include situations likeinvalid PA, unexpected severity, no memory failure config support,invalid GUID section, etc. In such a case, the user-space process willtrigger SEA again. This loop can potentially exceed the platformfirmware threshold or even trigger a kernel hard lockup, leading to asystem reboot.Fix it by performing a force kill if no memory_failure() work is queuedfor synchronous errors.[ rjw: Changelog edits ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: mdt_loader: Ensure we don't read past the ELF headerWhen the MDT loader is used in remoteproc, the ELF header is sanitizedbeforehand, but that's not necessary the case for other clients.Validate the size of the firmware buffer to ensure that we don't readpast the end as we iterate over the header. e_phentsize and e_shentsizeare validated as well, to ensure that the assumptions about step size inthe traversal are valid.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- coreutils < 8.25-13.19.1 (version in image is 8.25-13.16.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check NULL before accessing[WHAT]IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomicfails with NULL pointer dereference. This can be reproduced withboth an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ...(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in cp-demangle.c in GNU libiberty, as distributed in GNU Binutils 2.31. There is a stack consumption problem caused by the cplus_demangle_type function making recursive calls to itself in certain scenarios involving many 'P' characters.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The get_count function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31, allows remote attackers to cause a denial of service (malloc called with the result of an integer-overflowing calculation) or possibly have unspecified other impact via a crafted string, as demonstrated by c++filt.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in cp-demangle.c in GNU libiberty, as distributed in GNU Binutils 2.31. Stack Exhaustion occurs in the C++ demangling functions provided by libiberty, and there is a stack consumption problem caused by recursive stack frames: cplus_demangle_type, d_bare_function_type, d_function_type.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFC: st21nfca: Fix memory leak in device probe and remove'phy->pending_skb' is alloced when device probe, but forgot to freein the error handling path and remove path, this cause memory leakas follows:unreferenced object 0xffff88800bc06800 (size 512): comm "8", pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2Fix it by freeing 'pending_skb' in error and remove.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: A NULL pointer dereference was found In libssh during re-keying with algorithm guessing. This issue may allow an authenticated client to cause a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: config: fix iteration issue in 'usb_get_bos_descriptor()'The BOS descriptor defines a root descriptor and is the base descriptor foraccessing a family of related descriptors.Function 'usb_get_bos_descriptor()' encounters an iteration issue whenskipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results inthe same descriptor being read repeatedly.To address this issue, a 'goto' statement is introduced to ensure that thepointer and the amount read is updated correctly. This ensures that thefunction iterates to the next descriptor instead of reading the samedescriptor repeatedly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: fix memory leak of se_io context in nfc_genl_se_ioThe callback context for sending/receiving APDUs to/from the selectedsecure element is allocated inside nfc_genl_se_io and supposed to beeventually freed in se_io_cb callback function. However, there are severalerror paths where the bwi_timer is not charged to call se_io_cb later, andthe cb_context is leaked.The patch proposes to free the cb_context explicitly on those error paths.At the moment we can't simply check 'dev->ops->se_io()' return value as itmay be negative in both cases: when the timer was charged and was not.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds read vulnerability was found in the NVMe-oF/TCP subsystem in the Linux kernel. This issue may allow a remote attacker to send a crafted TCP packet, triggering a heap-based buffer overflow that results in kmalloc data being printed and potentially leaked to the kernel ring buffer (dmesg).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.189.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: roles: fix NULL pointer issue when put module's referenceIn current design, usb role class driver will get usb_role_switch parent'smodule reference after the user get usb_role_switch device and put thereference after the user put the usb_role_switch device. However, theparent device of usb_role_switch may be removed before the user put theusb_role_switch. If so, then, NULL pointer issue will be met when the userput the parent module's reference.This will save the module pointer in structure of usb_role_switch. Then,we don't need to find module by iterating long relations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: Rubygems.org is the Ruby community's gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libruby2_1-2_1 > 0-0 (version in image is 2.1.9-19.6.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Add poll mod list filling checkIn case of im_protocols value is 1 and tm_protocols value is 0 thiscombination successfully passes the check'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().But then after pn533_poll_create_mod_list() call in pn533_start_poll()poll mod list will remain empty and dev->poll_mod_count will remain 0which lead to division by zero.Normally no im protocol has value 1 in the mask, so this combination isnot expected by driver. But these protocol values actually come fromuserspace via Netlink interface (NFC_CMD_START_POLL operation). So abroken or malicious program may pass a message containing a "bad"combination of protocol parameter values so that dev->poll_mod_countis not incremented inside pn533_poll_create_mod_list(), thus leadingto division by zero.Call trace looks like:nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll()Add poll mod list filling check.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY onexit") will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue->xceivsunxi_musb_probe() -> devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -> sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()3) register @musb_driver againmusb_probe() -> sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.105.1 (version in image is 8.0.1-11.74.1).
-
Description: A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- rsync > 0-0 (version in image is 3.1.3-3.14.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: A flaw was found in Samba, in the vfs_streams_xattr module, where uninitialized heap memory could be written into alternate data streams. This allows an authenticated user to read residual memory content that may include sensitive data, resulting in an information disclosure vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- samba-client-libs < 4.15.13+git.664.e8416d8d213-3.99.1 (version in image is 4.15.13+git.625.ac658f2f12-3.88.1).
-
Description: urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- python-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
-
Description: Bluetooth LE and BR/EDR secure pairing in Bluetooth Core Specification 2.1 through 5.2 may permit a nearby man-in-the-middle attacker to identify the Passkey used during pairing (in the Passkey authentication procedure) by reflection of the public key and 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. The attack methodology determines the Passkey value one bit at a time.
Packages affected:
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
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 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_netlink: Fix shift out of bounds in group mask calculationWhen a netlink message is received, netlink_recvmsg() fills in the addressof the sender. One of the fields is the 32-bit bitfield nl_groups, whichcarries the multicast group on which the message was received. The leastsignificant bit corresponds to group 1, and therefore the highest groupthat the field can represent is 32. Above that, the UB sanitizer flags theout-of-bounds shift attempts.Which bits end up being set in such case is implementation defined, butit's either going to be a wrong non-zero value, or zero, which is at leastnot misleading. Make the latter choice deterministic by always setting to 0for higher-numbered multicast groups.To get information about membership in groups >= 32, userspace is expectedto use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFOsocket option.[0] https://lwn.net/Articles/147608/The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridgeWhich produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system's boot phase.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- shim < 15.8-25.30.1 (version in image is 15.7-25.27.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3-urllib3 < 1.25.10-3.37.1 (version in image is 1.25.10-3.34.1).
-
Description: This flaw allows a malicious HTTP server to set "super cookies" in curl thatare then passed back to more origins than what is otherwise allowed orpossible. This allows a site to set cookies that then would get sent todifferent and unrelated sites and domains.It could do this by exploiting a mixed case flaw in curl's function thatverifies a given cookie domain against the Public Suffix List (PSL). Forexample a cookie could be set with `domain=co.UK` when the URL used a lowercase hostname `curl.co.uk`, even though `co.uk` is listed as a PSL domain.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.80.1 (version in image is 8.0.1-11.74.1).
-
Description: Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpcap1 < 1.8.1-10.6.1 (version in image is 1.8.1-10.3.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: zr364xx: fix memory leak in zr364xx_start_readpipesyzbot reported memory leak in zr364xx driver.The problem was in non-freed urb in case ofusb_submit_urb() fail.backtrace: [] kmalloc include/linux/slab.h:561 [inline] [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] really_probe+0x159/0x500 drivers/base/dd.c:576
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock between quota disable and qgroup rescan workerQuota disable ioctl starts a transaction before waiting for the qgrouprescan worker completes. However, this wait can be infinite and resultsin deadlock because of circular dependency among the quota disableioctl, the qgroup rescan worker and the other task with transaction suchas block group relocation task.The deadlock happens with the steps following:1) Task A calls ioctl to disable quota. It starts a transaction and waits for qgroup rescan worker completes.2) Task B such as block group relocation task starts a transaction and joins to the transaction that task A started. Then task B commits to the transaction. In this commit, task B waits for a commit by task A.3) Task C as the qgroup rescan worker starts its job and starts a transaction. In this transaction start, task C waits for completion of the transaction that task A started and task B committed.This deadlock was found with fstests test case btrfs/115 and a zonednull_blk device. The test case enables and disables quota, and theblock group reclaim was triggered during the quota disable by chance.The deadlock was also observed by running quota enable and disable inparallel with 'btrfs balance' command on regular null_blk devices.An example report of the deadlock: [372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds. [372.479944] Not tainted 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000 [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Call Trace: [372.514092] [372.521684] __schedule+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] schedule+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? finish_wait+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960] ? do_raw_spin_lock+0x11e/0x250 [372.627137] ? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] worker_thread+0x59e/0xf90 [372.676172] ? process_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds. [372.729827] Not tainted 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000 [372.787776] Call Trace: [372.801652] [372.812961] __schedule+0xb56/0x4850 [372.830011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] schedule+0xe0/0x270 [372.901685] wait_current_trans+0x22c/0x310 [btrfs] [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs] [372.938923] ? finish_wait+0x270/0x270 [372.959085] ? join_transaction+0xc7---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efi: runtime: avoid EFIv2 runtime services on Apple x86 machinesAditya reports [0] that his recent MacbookPro crashes in the firmwarewhen using the variable services at runtime. The culprit appears to be acall to QueryVariableInfo(), which we did not use to call on Apple x86machines in the past as they only upgraded from EFI v1.10 to EFI v2.40firmware fairly recently, and QueryVariableInfo() (along withUpdateCapsule() et al) was added in EFI v2.00.The only runtime service introduced in EFI v2.00 that we actually use inLinux is QueryVariableInfo(), as the capsule based ones are optional,generally not used at runtime (all the LVFS/fwupd firmware updateinfrastructure uses helper EFI programs that invoke capsule update atboot time, not runtime), and not implemented by Apple machines in thefirst place. QueryVariableInfo() is used to 'safely' set variables,i.e., only when there is enough space. This prevents machines with buggyfirmwares from corrupting their NVRAMs when they run out of space.Given that Apple machines have been using EFI v1.10 services only forthe longest time (the EFI v2.0 spec was released in 2006, and Linuxsupport for the newly introduced runtime services was added in 2011, butthe MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),let's avoid the EFI v2.0 ones on all Apple x86 machines.[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: Work around an erratum on fast string copy instructionsA rare kernel panic scenario can happen when the following conditionsare met due to an erratum on fast string copy instructions:1) An uncorrected error.2) That error must be in first cache line of a page.3) Kernel must execute page_copy from the page immediately before thatpage.The fast string copy instructions ("REP; MOVS*") could consume anuncorrectable memory error in the cache line _right after_ the desiredregion to copy and raise an MCE.Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast stringcopy and will avoid such spurious machine checks. However, that is lesspreferable due to the permanent performance impact. Considering memorypoison is rare, it's desirable to keep fast string copy enabled until anMCE is seen.Intel has confirmed the following:1. The CPU erratum of fast string copy only applies to Skylake,Cascade Lake and Cooper Lake generations.Directly return from the MCE handler:2. Will result in complete execution of the "REP; MOVS*" with no dataloss or corruption.3. Will not result in another MCE firing on the next poisoned cache linedue to "REP; MOVS*".4. Will resume execution from a correct point in code.5. Will result in the same instruction that triggered the MCE firing asecond MCE immediately for any other software recoverable data fetcherrors.6. Is not safe without disabling the fast string copy, as the next faststring copy of the same buffer on the same CPU would result in a PANICMCE.This should mitigate the erratum completely with the only caveat thatthe fast string copy is disabled on the affected hyper thread thusperformance degradation.This is still better than the OS crashing on MCEs raised on anirrelevant process due to "REP; MOVS*' accesses in a kernel context,e.g., copy_page.Injected errors on 1st cache line of 8 anonymous pages of process'proc1' and observed MCE consumption from 'proc2' with no panic(directly returned).Without the fix, the host panicked within a few minutes on arandom 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drivers/md/md-bitmap: check the return value of md_bitmap_get_counter()Check the return value of md_bitmap_get_counter() in case it returnsNULL pointer, which will result in a null pointer dereference.v2: update the check to include other dereference
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/tunnel: wait until all sk_user_data reader finish before releasing the sockThere is a race condition in vxlan that when deleting a vxlan deviceduring receiving packets, there is a possibility that the sock isreleased after getting vxlan_sock vs from sk_user_data. Then inlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will gotNULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.shFix this by waiting for all sk_user_data reader to finish beforereleasing the sock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: fcoe: Fix transport not deattached when fcoe_if_init() failsfcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but whenfcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed&fcoe_sw_transport on fcoe_transports list. This causes panic whenreinserting module. BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: do_one_initcall+0xd0/0x4e0 load_module+0x5eee/0x7210 ...
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Perform lockless command completion in abort pathWhile adding and removing the controller, the following call trace wasobserved:WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1RIP: 0010:dma_free_attrs+0x33/0x50Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xaeThe command was completed in the abort path during driver unload with alock held, causing the warning in abort path. Hence complete the commandwithout any lock held.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Reinit port->pm on port specific driver unbindWhen we unbind a serial port hardware specific 8250 driver, the genericserial8250 driver takes over the port. After that we see an oops about 10seconds later. This can produce the following at least on some TI SoCs:Unhandled fault: imprecise external abort (0x1406)Internal error: : 1406 [#1] SMP ARMTurns out that we may still have the serial port hardware specific driverport->pm in use, and serial8250_pm() tries to call it after the portspecific driver is gone:serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c__tty_hangup.part.0 from disassociate_ctty+0x154/0x20cdisassociate_ctty from do_exit+0x744/0xaacdo_exit from do_group_exit+0x40/0x8cdo_group_exit from __wake_up_parent+0x0/0x1cLet's fix the issue by calling serial8250_set_defaults() inserial8250_unregister_port(). This will set the port back to usingthe serial8250 default functions, and sets the port->pm to point toserial8250_pm.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAFAfter a call to console_unlock() in vcs_write() the vc_data struct can befreed by vc_port_destruct(). Because of that, the struct vc_data pointermust be reloaded in the while loop in vcs_write() after console_lock() toavoid a UAF when vcs_size() is called.Syzkaller reported a UAF in vcs_size().BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119Call Trace: __asan_report_load4_noabort (mm/kasan/report_generic.c:380)vcs_size (drivers/tty/vt/vc_screen.c:215)vcs_write (drivers/tty/vt/vc_screen.c:664)vfs_write (fs/read_write.c:582 fs/read_write.c:564)... Allocated by task 1213:kmalloc_trace (mm/slab_common.c:1064)vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680 drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058)con_install (drivers/tty/vt/vt.c:3334)tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415 drivers/tty/tty_io.c:1392)tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128)chrdev_open (fs/char_dev.c:415)do_dentry_open (fs/open.c:921)vfs_open (fs/open.c:1052)...Freed by task 4116:kfree (mm/slab_common.c:1016)vc_port_destruct (drivers/tty/vt/vt.c:1044)tty_port_destructor (drivers/tty/tty_port.c:296)tty_port_put (drivers/tty/tty_port.c:312)vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)tty_ioctl (drivers/tty/tty_io.c:2778)...The buggy address belongs to the object at ffff8880beab8800 which belongs to the cache kmalloc-1k of size 1024The buggy address is located 424 bytes inside of freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)The buggy address belongs to the physical page:page:00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbeab8head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)page_type: 0xffffffff()raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb>ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================Disabling lock debugging due to kernel taint
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Add a check for valid 'mad_agent' pointerWhen unregistering MAD agent, srpt module has a non-null checkfor 'mad_agent' pointer before invoking ib_unregister_mad_agent().This check can pass if 'mad_agent' variable holds an error value.The 'mad_agent' can have an error value for a short window whensrpt_add_one() and srpt_remove_one() is executed simultaneously.In srpt module, added a valid pointer check for 'sport->mad_agent'before unregistering MAD agent.This issue can hit when RoCE driver unregisters ib_deviceStack Trace:------------BUG: kernel NULL pointer dereference, address: 000000000000004dPGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0Oops: 0002 [#1] PREEMPT SMP NOPTICPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: PHardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020Workqueue: bnxt_re bnxt_re_task [bnxt_re]RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40Call Trace: ib_unregister_mad_agent+0x46/0x2f0 [ib_core] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready ? __schedule+0x20b/0x560 srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt] srpt_remove_one+0x20/0x150 [ib_srpt] remove_client_context+0x88/0xd0 [ib_core] bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex disable_device+0x8a/0x160 [ib_core] bond0: active interface up! ? kernfs_name_hash+0x12/0x80 (NULL device *): Bonding Info Received: rdev: 000000006c0b8247 __ib_unregister_device+0x42/0xb0 [ib_core] (NULL device *): Master: mode: 4 num_slaves:2 ib_unregister_device+0x22/0x30 [ib_core] (NULL device *): Slave: id: 105069936 name:p2p1 link:0 state:0 bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re] bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix a race between readers and resize checksThe reader code in rb_get_reader_page() swaps a new reader page into thering buffer by doing cmpxchg on old->list.prev->next to point it to thenew page. Following that, if the operation is successful,old->list.next->prev gets updated too. This means the underlyingdoubly-linked list is temporarily inconsistent, page->prev->next orpage->next->prev might not be equal back to page for some page in thering buffer.The resize operation in ring_buffer_resize() can be invoked in parallel.It calls rb_check_pages() which can detect the described inconsistencyand stop further tracing:[ 190.271762] ------------[ cut here ]------------[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0[ 190.271789] Modules linked in: [...][ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0[ 190.272023] Code: [...][ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 190.272077] Call Trace:[ 190.272098] [ 190.272189] ring_buffer_resize+0x2ab/0x460[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0[ 190.272206] tracing_resize_ring_buffer+0x65/0x90[ 190.272216] tracing_entries_write+0x74/0xc0[ 190.272225] vfs_write+0xf5/0x420[ 190.272248] ksys_write+0x67/0xe0[ 190.272256] do_syscall_64+0x82/0x170[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 190.272373] RIP: 0033:0x7f1bd657d263[ 190.272381] Code: [...][ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002[ 190.272412] [ 190.272414] ---[ end trace 0000000000000000 ]---Note that ring_buffer_resize() calls rb_check_pages() only if the parenttrace_buffer has recording disabled. Recent commit d78ab792705c("tracing: Stop current tracer when resizing buffer") causes that it isnow always the case which makes it more likely to experience this issue.The window to hit this race is nonetheless very small. To helpreproducing it, one can add a delay loop in rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */ __asm__ __volatile__ ("" : : : "memory"); rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;.. ---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of protected- and secure-keysAlthough the clear-key of neither protected- nor secure-keys isaccessible, this key material should only be visible to the callingprocess. So wipe all copies of protected- or secure-keys from stack,even in case of an error.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: aead,cipher - zeroize key buffer after useI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holdingcryptographic information should be zeroized once they are no longerneeded. Accomplish this by using kfree_sensitive for buffers thatpreviously held the private key.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: check device is present when getting link settingsA sysfs reader can race with a device reset or removal, attempting toread device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5,state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).The device is not present, note lack of __LINK_STATE_PRESENT (0b10).This is the same sort of panic as observed in commit 4224cfd7fb65("net-sysfs: add check for netdevice being present to speed_show").There are many other callers of __ethtool_get_link_ksettings() whichdon't have a device presence check.Move this check into ethtool to protect all callers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesA bogus device can provide a bNumConfigurations value that exceeds theinitial value used in usb_get_configuration for allocating dev->config.This can lead to out-of-bounds accesses later, e.g. inusb_destroy_configuration.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: mctrl_gpio: split disable_ms into sync and no_sync APIsThe following splat has been observed on a SAMA5D27 platform usingatmel_serial:BUG: sleeping function called from invalid context at kernel/irq/manage.c:738in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0preempt_count: 1, expected: 0INFO: lockdep is turned off.irq event stamp: 0hardirqs last enabled at (0): [<00000000>] 0x0hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7becsoftirqs last enabled at (0): [] copy_process+0x1ca0/0x7becsoftirqs last disabled at (0): [<00000000>] 0x0CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74Hardware name: Atmel SAMA5Workqueue: hci0 hci_power_on [bluetooth]Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28This warning is emitted when trying to toggle, at the highest level,some flow control (with serdev_device_set_flow_control) in a devicedriver. At the lowest level, the atmel_serial driver is usingserial_mctrl_gpio lib to enable/disable the corresponding IRQsaccordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due todisable_irq (called in mctrl_gpio_disable_ms) being possibly called insome atomic context (some tty drivers perform modem lines configurationin regions protected by port lock).Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking oneand a blocking one. Replace mctrl_gpio_disable_ms calls with therelevant version depending on whether the call is protected by some portlock.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,running at UDMA/33.The issue can be reproduced by running the same command with a cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar 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.1552 contains a patch for the vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: The commandline package update tool zypper writes HTTP proxy credentials into its logfile, allowing local attackers to gain access to proxies used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libzypp < 16.22.13-65.3 (version in image is 16.22.8-51.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hso: fix NULL-deref on disconnect regressionCommit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty deviceunregistration") fixed the racy minor allocation reported by syzbot, butintroduced an unconditional NULL-pointer dereference on every disconnectinstead.Specifically, the serial device table must no longer be accessed afterthe minor has been released by hso_serial_tty_unregister().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:asix: fix uninit-value in asix_mdio_read()asix_read_cmd() may read less than sizeof(smsr) bytes and in this casesmsr will be uninitialized.Fail log:BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: mceusb: Use new usb_control_msg_*() routinesAutomatic kernel fuzzing led to a WARN about invalid pipe direction inthe mceusb driver:------------[ cut here ]------------usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410Modules linked in:CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.13.0-1ubuntu1.1 04/01/2014Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e844 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0be9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41RSP: 0018:ffffc900032becf0 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0Call Trace:usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58usb_internal_control_msg drivers/usb/core/message.c:102 [inline]usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807The reason for the warning is clear enough; the driver sends anunusual read request on endpoint 0 but does not set the USB_DIR_IN bitin the bRequestType field.More importantly, the whole situation can be avoided and the driversimplified by converting it over to the relatively newusb_control_msg_recv() and usb_control_msg_send() routines. That'swhat this fix does.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.186.1 (version in image is 4.12.14-122.179.1).
-
Description: When saving HSTS data to an excessively long file name, curl could end upremoving all contents, making subsequent requests using that file unaware ofthe HSTS status they should otherwise use.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.80.1 (version in image is 8.0.1-11.74.1).
-
Description: Vim is an improved version of the good old UNIX editor Vi. Heap-use-after-free in memory allocated in the function `ga_grow_inner` in in the file `src/alloc.c` at line 748, which is freed in the file `src/ex_docmd.c` in the function `do_cmdline` at line 1010 and then used again in `src/cmdhist.c` at line 759. When using the `:history` command, it's possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free. This vulnerability has been patched in version 9.0.2068.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.0.2103-17.26.1 (version in image is 9.0.1894-17.23.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Do not use WQ_MEM_RECLAIM flag for workqueueWhen both ice and the irdma driver are loaded, a warning incheck_flush_dependency is being triggered. This is due to ice driverworkqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma oneis not.According to kernel documentation, this flag should be set if theworkqueue will be involved in the kernel's memory reclamation flow.Since it is not, there is no need for the ice driver's WQ to have thisflag set so remove it.Example trace:[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbsib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meteracpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit libata dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse[ +0.000161] [last unloaded: bonding][ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020[ +0.000003] Workqueue: ice ice_service_task [ice][ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 089f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ +0.000002] PKRU: 55555554[ +0.000003] Call Trace:[ +0.000002] [ +0.000003] __flush_workqueue+0x203/0x840[ +0.000006] ? mutex_unlock+0x84/0xd0[ +0.000008] ? __pfx_mutex_unlock+0x10/0x10[ +0.000004] ? __pfx___flush_workqueue+0x10/0x10[ +0.000006] ? mutex_lock+0xa3/0xf0[ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core][ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core][ +0.000094] ib_unregister_device+0x25/0x30 [ib_core][ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma][ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma][ +0.000059] ? up_write+0x5c/0x90[ +0.000005] irdma_remove+0x36/0x90 [irdma][ +0.000062] auxiliary_bus_remove+0x32/0x50[ +0.000007] device_r---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1969.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.0.2103-17.26.1 (version in image is 9.0.1894-17.23.2).
-
Description: Debian's cpio contains a path traversal vulnerability. This issue was introduced by reverting CVE-2015-1197 patches which had caused a regression in --no-absolute-filenames. Upstream has since provided a proper fix to --no-absolute-filenames.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- cpio < 2.11-36.21.1 (version in image is 2.11-36.15.1).
-
Description: nscd: netgroup cache assumes NSS callback uses in-buffer stringsThe Name Service Cache Daemon's (nscd) netgroup cache can corrupt memorywhen the NSS callback does not store all strings in the provided buffer.The flaw was introduced in glibc 2.15 when the cache was added to nscd.This vulnerability is only present in the nscd binary.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc < 2.22-114.34.1 (version in image is 2.22-114.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: systemport: fix potential memory leak in bcm_sysport_xmit()The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skbin case of dma_map_single() fails, add dev_kfree_skb() to fix it.
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a NULL pointer dereference in xmlPatMatch in pattern.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 < 2.9.4-46.81.1 (version in image is 2.9.4-46.65.1).
-
Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- expat > 0-0 (version in image is 2.1.0-21.28.1).
-
Description: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libgnutls30 > 0-0 (version in image is 3.4.17-8.14.1).
-
Description: The pe_bfd_read_buildid function in peicode.h in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, does not validate size and offset values in the data dictionary, which allows remote attackers to cause a denial of service (segmentation violation and application crash) or possibly have unspecified other impact via a crafted PE file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory access exists in bfd_zalloc in opncls.c. Attackers could leverage this vulnerability to cause a denial of service (application crash) via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A NULL pointer dereference was discovered in elf_link_add_object_symbols in elflink.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31.1. This occurs for a crafted ET_DYN with no program headers. A specially crafted ELF file allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In SQLite through 3.22.0, databases whose schema is corrupted using a CREATE TABLE AS statement could cause a NULL pointer dereference, related to build.c and prepare.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sqlite3-tcl > 0-0 (version in image is 3.39.3-9.26.1).
-
Description: The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to use of the ssl_context, ca_certs, or ca_certs_dir argument.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- grub2 < 2.02-181.2 (version in image is 2.02-169.1).
-
Description: Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source, command line text editor. A use-after-free was found in Vim < 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.
Packages affected:
- glib2-tools < 2.48.2-12.40.1 (version in image is 2.48.2-12.34.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Python Cryptographic Authority pyopenssl version Before 17.5.0 contains a CWE - 401 : Failure to Release Memory Before Removing Last Reference vulnerability in PKCS #12 Store that can result in Denial of service if memory runs low or is exhausted. This attack appear to be exploitable via Depends upon calling application, however it could be as simple as initiating a TLS connection. Anything that would cause the calling application to reload certificates from a PKCS #12 store.. This vulnerability appears to have been fixed in 17.5.0.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-pyOpenSSL < 17.1.0-4.26.1 (version in image is 17.1.0-4.23.1).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2022-2964. Reason: This candidate is a reservation duplicate of CVE-2022-2964. Notes: All CVE users should reference CVE-2022-2964 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: The coff_slurp_line_table function in coffcode.h in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, allows remote attackers to cause a denial of service (invalid memory access and application crash) or possibly have unspecified other impact via a crafted PE file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: The "ipaddress" module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as "globally reachable" or "private". This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn't be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.
Packages affected:
- libpython3_4m1_0 < 3.4.10-25.133.1 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glib2-tools > 0-0 (version in image is 2.48.2-12.34.1).
-
Description: Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.15.1 (version in image is 0.8.7-3.9.1).
-
Description: The getNodeSize function in ext/rtree/rtree.c in SQLite through 3.19.3, as used in GDAL and other products, mishandles undersized RTree blobs in a crafted database, leading to a heap-based buffer over-read or possibly unspecified other impact.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- sqlite3-tcl > 0-0 (version in image is 3.39.3-9.26.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bnx2fc: Make bnx2fc_recv_frame() mp safeRunning tests with a debug kernel shows that bnx2fc_recv_frame() ismodifying the per_cpu lport stats counters in a non-mpsafe way. Just boota debug kernel and run the bnx2fc driver with the hardware enabled.[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc][ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013[ 1391.699183] Call Trace:[ 1391.699188] dump_stack_lvl+0x57/0x7d[ 1391.699198] check_preemption_disabled+0xc8/0xd0[ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc][ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180[ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc][ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc][ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc][ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc][ 1391.699258] kthread+0x364/0x420[ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50[ 1391.699268] ? set_kthread_struct+0x100/0x100[ 1391.699273] ret_from_fork+0x22/0x30Restore the old get_cpu/put_cpu code with some modifications to reduce thesize of the critical section.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs().KCSAN found a data race in sock_recv_cmsgs() where the read accessto sk->sk_stamp needs READ_ONCE().BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsgwrite (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0: sock_write_timestamp include/net/sock.h:2670 [inline] sock_recv_cmsgs include/net/sock.h:2722 [inline] packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1: sock_recv_cmsgs include/net/sock.h:2721 [inline] packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0xffffffffc4653600 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: Add validation for completion descriptors consistencyValidate that `first` flag is set only for the firstdescriptor in multi-buffer packets.In case of an invalid descriptor, a reset will occur.A new reset reason for RX data corruption has been added.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched 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.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_regsyzbot reported the following uninit-value access issue:=====================================================BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482This issue is caused because usbnet_read_cmd() reads less bytes than requested(zero byte in the reproducer). In this case, 'buf' is not properly filled.This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() readsless bytes than requested.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled. curl --proto -all,-http http://curl.se The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.86.2 (version in image is 8.0.1-11.74.1).
-
Description: A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating "secret_hash" of different size than the session_id has. This becomes an issue when the session_id memory is zeroed or when it is used again during second key re-exchange.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 < 0.9.8-3.12.2 (version in image is 0.8.7-3.9.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:calipso: fix memory leak in netlbl_calipso_add_pass()If IPv6 support is disabled at boot (ipv6.disable=1),the calipso_init() -> netlbl_calipso_ops_register() function isn't called,and the netlbl_calipso_ops_get() function always returns NULL.In this case, the netlbl_calipso_add_pass() function allocates memoryfor the doi_def variable but doesn't free it with the calipso_doi_free().BUG: memory leakunreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller[PM: merged via the LSM tree at Jakub Kicinski request]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()In resp_mode_select() sanity check the block descriptor len to avoid UAF.BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509Read of size 1 at addr ffff888026670f50 by task scsicmd/15032CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSCall Trace: dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483 scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537 scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: The display_debug_ranges function in dwarf.c in GNU Binutils 2.30 allows remote attackers to cause a denial of service (integer overflow and application crash) or possibly have unspecified other impact via a crafted ELF file, as demonstrated by objdump.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libfl2 > 0-0 (version in image is 2.6.4-9.7.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvbdev: Fix memory leak in dvb_media_device_free()dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`before setting it to NULL, as documented in include/media/media-device.h:"The media_entity instance itself must be freed explicitly by the driverif required."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cadence: fix reference leak when pm_runtime_get_sync failsThe PM reference count is not expected to be incremented onreturn in functions cdns_i2c_master_xfer and cdns_reg_slave.However, pm_runtime_get_sync will increment pm usage countereven failed. Forgetting to putting operation will result in areference leak here.Replace it with pm_runtime_resume_and_get to keep usagecounter balanced.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: keep alloc_hash updated after hash allocationIn commit 599be01ee567 ("net_sched: fix an OOB access in cls_tcindex")I moved cp->hash calculation before the firsttcindex_alloc_perfect_hash(), but cp->alloc_hash is left untouched.This difference could lead to another out of bound access.cp->alloc_hash should always be the size allocated, we shouldupdate it after this tcindex_alloc_perfect_hash().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: properly indicate failure when ending a failed write requestThis patch addresses a data corruption bug in raid1 arrays using bitmaps.Without this fix, the bitmap bits for the failed I/O end up being cleared.Since we are in the failure leg of raid1_end_write_request, the requesteither needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-loop: fix memory leak in nvme_loop_create_ctrl()When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl()fails, the loop ctrl should be freed before jumping to the "out" label.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kvm: Teardown PV features on boot CPU as wellVarious PV features (Async PF, PV EOI, steal time) work through memoryshared with hypervisor and when we restore from hibernation we mustproperly teardown all these features to make sure hypervisor doesn'twrite to stale locations after we jump to the previously hibernated kernel(which can try to place anything there). For secondary CPUs the job isalready done by kvm_cpu_down_prepare(), register syscore ops to dothe same for boot CPU.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: advansys: Fix kernel pointer leakPointers should be printed with %p or %px rather than cast to 'unsignedlong' and printed with %lx.Change %lx to %p to print the hashed pointer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix error handling of scsi_host_alloc()After device is initialized via device_initialize(), or its name is set viadev_set_name(), the device has to be freed via put_device(). Otherwisedevice name will be leaked because it is allocated dynamically indev_set_name().Fix the leak by replacing kfree() with put_device(). Sincescsi_host_dev_release() properly handles IDA and kthread removal, removespecial-casing these from the error handling as well.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: 8250: serial_cs: Fix a memory leak in error handling pathIn the probe function, if the final 'serial_config()' fails, 'info' isleaking.Add a resource handling path to free this memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Fix rdma_resolve_route() memory leakFix a memory leak when "mda_resolve_route() is called more than once onthe same "rdma_cm_id".This is possible if cma_query_handler() triggers theRDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back andallows rdma_resolve_route() to be called again.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Fix potential VPE leak on errorIn its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,there is an off-by-one in the number of VPEs to be freed.Fix it by simply passing the number of VPEs allocated, which is theindex of the loop iterating over the VPEs.[maz: fixed commit message]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/debugfs: fix file release memory leakWhen using single_open() for opening, single_release() should becalled, otherwise the 'op' allocated in single_open() will be leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix gart.bo pin_count leakgmc_v{9,10}_0_gart_disable() isn't called matched withcorrespoding gart_enbale function in SRIOV case. This willlead to gart.bo pin_count leak on driver unload.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: sanity check for maxpacketmaxpacket of 0 makes no sense and oopses as we need to divideby it. Give up.V2: fixed typo in log and stylistic issues
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfp: Fix memory leak in nfp_cpp_area_cache_add()In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes aCPP area structure. But in line 807 (#2), when the cache is allocatedfailed, this CPP area structure is not freed, which will result inmemory leak.We can fix it by freeing the CPP area when the cache is allocatedfailed (#2).792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)793 {794 struct nfp_cpp_area_cache *cache;795 struct nfp_cpp_area *area;800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),801 0, size); // #1: allocates and initializes802 if (!area)803 return -ENOMEM;805 cache = kzalloc(sizeof(*cache), GFP_KERNEL);806 if (!cache)807 return -ENOMEM; // #2: missing free817 return 0;818 }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddrThis buffer is currently allocated in hfi1_init(): if (reinit) ret = init_after_reset(dd); else ret = loadtime_init(dd); if (ret) goto done; /* allocate dummy tail memory for all receive contexts */ dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); if (!dd->rcvhdrtail_dummy_kvaddr) { dd_dev_err(dd, "cannot allocate dummy tail memory\n"); ret = -ENOMEM; goto done; }The reinit triggered path will overwrite the old allocation and leak it.Fix by moving the allocation to hfi1_alloc_devdata() and the deallocationto hfi1_free_devdata().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:inet_diag: fix kernel-infoleak for UDP socketsKMSAN reported a kernel-infoleak [1], that can exploitedby unpriv users.After analysis it turned out UDP was not initializingr->idiag_expires. Other users of inet_sk_diag_fill()might make the same mistake in the future, so fix thisin inet_sk_diag_fill().[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:156 [inline] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [inline] new_sync_read fs/read_write.c:400 [inline] vfs_read+0x1631/0x1980 fs/read_write.c:481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [inline] __se_sys_read fs/read_write.c:627 [inline] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeBytes 68-71 of 312 are uninitializedMemory access of size 312 starts at ffff88812ab54000Data copied to user address 0000000020001440CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: staging: media: zoran: move videodev allocMove some code out of zr36057_init() and create new functions for handlingzr->video_dev. This permit to ease code reading and fix a zr->video_devmemory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/plane: Move range check for format_count earlierWhile the check for format_count > 64 in __drm_universal_plane_init()shouldn't be hit (it's a WARN_ON), in its current position it will thenleak the plane->format_types array and fail to calldrm_mode_object_unregister() leaking the modeset identifier. Move it tothe start of the function to avoid allocating those resources in thefirst place.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobjkobject_init_and_add() takes reference even when it fails.According to the doc of kobject_init_and_add(): If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.Fix memory leak by calling kobject_put().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: at86rf230: Stop leaking skb'sUpon error the ieee802154_xmit_complete() helper is not called. Onlyieee802154_wake_queue() is called manually. In the Tx case we then leakthe skb structure.Free the skb structure upon error before returning when appropriate.As the 'is_tx = 0' cannot be moved in the complete handler because of apossible race between the delay in switching to STATE_RX_AACK_ON and anew interrupt, we introduce an intermediate 'was_tx' boolean just forthis purpose.There is no Fixes tag applying here, many changes have been made on thisarea and the issue kind of always existed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix refcount issue when LOGO is received during TMFHung task call trace was seen during LOGO processing.[ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued...[ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0[ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET[ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1.[ 974.309625] host1: rport 016900: Received LOGO request while in state Ready[ 974.309627] host1: rport 016900: Delete port[ 974.309642] host1: rport 016900: work event 3[ 974.309644] host1: rport 016900: lld callback ev 3[ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush.[ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success...[ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds.[ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1[ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080[ 984.031212] Call Trace:[ 984.031222] __schedule+0x2c4/0x700[ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0[ 984.031233] ? bit_wait_timeout+0x90/0x90[ 984.031235] schedule+0x38/0xa0[ 984.031238] io_schedule+0x12/0x40[ 984.031240] bit_wait_io+0xd/0x50[ 984.031243] __wait_on_bit+0x6c/0x80[ 984.031248] ? free_buffer_head+0x21/0x50[ 984.031251] out_of_line_wait_on_bit+0x91/0xb0[ 984.031257] ? init_wait_var_entry+0x50/0x50[ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2][ 984.031280] kjournald2+0xbd/0x270 [jbd2][ 984.031284] ? finish_wait+0x80/0x80[ 984.031291] ? commit_timeout+0x10/0x10 [jbd2][ 984.031294] kthread+0x116/0x130[ 984.031300] ? kthread_flush_work_fn+0x10/0x10[ 984.031305] ret_from_fork+0x1f/0x40There was a ref count issue when LOGO is received during TMF. This leads toone of the I/Os hanging with the driver. Fix the ref count.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix leaking sent_cmd skbsent_cmd memory is not freed before freeing hci_dev causing it to leakit contents.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: free reset-work-item when flushingFix a tiny memory leak when flushing the reset work queue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix PCI device refcount leak in has_external_pci()for_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() before 'return true' to avoid reference count leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix leak of nested actionsWhile parsing user-provided actions, openvswitch module may dynamicallyallocate memory and store pointers in the internal copy of the actions.So this memory has to be freed while destroying the actions.Currently there are only two such actions: ct() and set(). However,there are many actions that can hold nested lists of actions andovs_nla_free_flow_actions() just jumps over them leaking the memory.For example, removal of the flow with the following actions will leadto a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0)Non-freed set() action may also leak the 'dst' structure for thetunnel info including device references.Under certain conditions with a high rate of flow rotation that maycause significant memory leak problem (2MB per second in reporter'scase). The problem is also hard to mitigate, because the user doesn'thave direct control over the datapath flows generated by OVS.Fix that by iterating over all the nested actions and freeingeverything that needs to be freed recursively.New build time assertion should protect us from this problem if newactions will be added in the future.Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so allattributes has to be explicitly checked. sample() and clone() actionsare mixing extra attributes into the user-provided action list. Thatprevents some code generalization too.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/iommu: Add missing of_node_put in iommu_init_early_dartThe device_node pointer is returned by of_find_compatible_nodewith refcount incremented. We should use of_node_put() to avoidthe refcount leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()If device_register() fails in tcm_loop_setup_hba_bus(), the name allocatedby dev_set_name() need be freed. As comment of device_register() says, itshould use put_device() to give up the reference in the error path. So fixthis by calling put_device(), then the name can be freed in kobject_cleanup().The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't needgoto error label in this case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()pci_get_device() will increase the reference count for the returnedpci_dev. We need to use pci_dev_put() to decrease the reference countbefore amd_probe() returns. There is no problem for the 'smbus_dev ==NULL' branch because pci_dev_put() can also handle the NULL inputparameter case.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,which may carry uninitialized data to the userspace, as observed byKMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100Use memset() to prevent the infoleaks.Also speculatively fix qp_notify_peer_local(), which may suffer from thesame problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: fix possible memory leak in mISDN_dsp_element_register()Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device'sbus_id string array"), the name of device is allocated dynamically,use put_device() to give up the reference, so that the name can befreed in kobject_cleanup() when the refcount is 0.The 'entry' is going to be freed in mISDN_dsp_dev_release(), so thekfree() is removed. list_del() is called in mISDN_dsp_dev_release(),so it need be initialized.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix connections leak when tlink setup failedIf the tlink setup failed, lost to put the connections, thenthe module refcnt leak since the cifsd kthread not exit.Also leak the fscache info, and for next mount with fsc, it willprint the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)Let's check the result of tlink setup, and do some cleanup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: fix fence ref countingWe leaked dependency fences when processes were beeing killed.Additional to that grab a reference to the last scheduled fence.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:capabilities: fix undefined behavior in bit shift for CAP_TO_MASKShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0 __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: clear optc underflow before turn off odm clock[Why]After ODM clock off, optc underflow bit will be kept there always and clear not work.We need to clear that before clock off.[How]Clear that if have when clock off.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix memory leak in ocfs2_stack_glue_init()ocfs2_table_header should be free in ocfs2_stack_glue_init() ifocfs2_sysfs_init() failed, otherwise kmemleak will report memleak.BUG: memory leakunreferenced object 0xffff88810eeb5800 (size 128): comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0 [<00000000c04f70f7>] 0xffffffffa0050037 [<000000001bd12912>] do_one_initcall+0xdb/0x480 [<0000000064f766c9>] do_init_module+0x1cf/0x680 [<000000002ba52db0>] load_module+0x6441/0x6f20 [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0 [<00000000380c1f22>] do_syscall_64+0x3f/0x90 [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leakIn crb_acpi_add(), we get the TPM2 table to retrieve informationlike start method, and then assign them to the priv data, so theTPM2 table is not used after the init, should be freed, callacpi_put_table() to fix the memory leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()Syzkaller reports a long-known leak of urbs inath9k_hif_usb_dealloc_tx_urbs().The cause of the leak is that usb_get_urb() is called but usb_free_urb()(or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev orurb->ep fields have not been initialized and usb_kill_urb() returnsimmediately.The patch removes trying to kill urbs located in hif_dev->tx.tx_bufbecause hif_dev->tx.tx_buf is not supposed to contain urbs which are inpending state (the pending urbs are stored in hif_dev->tx.tx_pending).The tx.tx_lock is acquired so there should not be any changes in the list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requestshfi1 user SDMA request processing has two bugs that can cause datacorruption for user SDMA requests that have multiple payload iovecswhere an iovec other than the tail iovec does not run up to the pageboundary for the buffer pointed to by that iovec.aHere are the specific bugs:1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet.2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages.This has not been an issue with SDMA packets from hfi1 Verbs or PSM2because they only produce iovecs that end short of PAGE_SIZE as the tailiovec of an SDMA request.Fixing these bugs exposes other bugs with the SDMA pin cache(struct mmu_rb_handler) that get in way of supporting user SDMA requestswith multiple payload iovecs whose buffers do not end at PAGE_SIZE. Sothis commit fixes those issues as well.Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovecpayload user SDMA requests can hit:1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings.2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3).3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented.4. Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those SDMA requests complete.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG commandTags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freedwhen we receive the response.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NTB: fix possible name leak in ntb_register_device()If device_register() fails in ntb_register_device(), the device nameallocated by dev_set_name() should be freed. As per the comment indevice_register(), callers should use put_device() to give up thereference in the error path. So fix this by calling put_device() in theerror path so that the name can be freed in kobject_cleanup().As a result of this, put_device() in the error path ofntb_register_device() is removed and the actual error is returned.[mani: reworded commit message]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix a memleak in gss_import_v2_contextThe ctx->mech_used.data allocated by kmemdup is not freed in neithergss_import_v2_context nor it only caller gss_krb5_import_sec_context,which frees ctx on error.Thus, this patch reform the last call of gss_import_v2_context to thegss_krb5_import_ctx_v2, preventing the memleak while keepping the returnformation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/usb: kalmia: Don't pass act_len in usb_bulk_msg error pathsyzbot reported that act_len in kalmia_send_init_packet() isuninitialized when passing it to the first usb_bulk_msg error path. JiriPirko noted that it's pointless to pass it in the error path, and thatthe value that would be printed in the second error path would be thevalue of act_len from the first call to usb_bulk_msg.[1]With this in mind, let's just not pass act_len to the usb_bulk_msg errorpaths.1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Bail out early if the request AUX area is out of boundWhen perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8'rb->aux_pages' allocated by kcalloc() is a pointer array which is used tomaintains AUX trace pages. The allocated page for this array is physicallycontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If thesize of pointer array crosses the limitation set by MAX_ORDER, it reveals aWARNING.So bail out early with -ENOMEM if the request AUX area is out of bound,e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix WARNING in ext4_update_inline_dataSyzbot found the following issue:EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"fscrypt: AES-256-XTS using implementation "xts-aes-aesni"------------[ cut here ]------------WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525Modules linked in:CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3cFS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __alloc_pages_node include/linux/gfp.h:237 [inline] alloc_pages_node include/linux/gfp.h:260 [inline] __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113 __do_kmalloc_node mm/slab_common.c:956 [inline] __kmalloc+0xfe/0x190 mm/slab_common.c:981 kmalloc include/linux/slab.h:584 [inline] kzalloc include/linux/slab.h:720 [inline] ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346 ext4_update_inline_dir fs/ext4/inline.c:1115 [inline] ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307 ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385 ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772 ext4_create+0x36c/0x560 fs/ext4/namei.c:2817 lookup_open fs/namei.c:3413 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x12ac/0x2dd0 fs/namei.c:3711 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_openat fs/open.c:1342 [inline] __se_sys_openat fs/open.c:1337 [inline] __x64_sys_openat+0x243/0x290 fs/open.c:1337 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdAbove issue happens as follows:ext4_iget ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60ext4_try_add_inline_entry __ext4_mark_inode_dirty ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44 ext4_xattr_shift_entries ->after shift i_inline_off is incorrect, actually is change to 176ext4_try_add_inline_entry ext4_update_inline_dir get_max_inline_xattr_value_size if (EXT4_I(inode)->i_inline_off) entry = (struct ext4_xattr_entry *)((void *)raw_inode + EXT4_I(inode)->i_inline_off); free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)); ->As entry is incorrect, then 'free' may be negative ext4_update_inline_data value = kzalloc(len, GFP_NOFS); -> len is unsigned int, maybe very large, then trigger warning when 'kzalloc()'To resolve the above issue we need to update 'i_inline_off' after'ext4_xattr_shift_entries()'. We do not need to setEXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATAwhen it is needed may trigger a BUG_ON in ext4_writepages().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: zero i_disksize when initializing the bootloader inodeIf the boot loader inode has never been used before, theEXT4_IOC_SWAP_BOOT inode will initialize it, including setting thei_size to 0. However, if the "never before used" boot loader has anon-zero i_size, then i_disksize will be non-zero, and theinconsistency between i_size and i_disksize can trigger a kernelwarning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024);Fix this by setting i_disksize as well as i_size to zero wheninitiaizing the boot loader inode.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), forcrafted filesystem image can contain bogus length. There conditions arenot kernel bugs that can justify kernel to panic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix GID entry ref leak when create_ah failsIf AH create request fails, release sgid_attr to avoid GID entryreferrence leak reported while releasing GID table
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/qedr: Fix qedr_create_user_qp error flowAvoid the following warning by making sure to free the allocatedresources in case that qedr_init_user_queue() fail.-----------[ cut here ]-----------WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ffRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0Call Trace:? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]? __warn+0x81/0x110? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]ib_uverbs_close+0x1f/0xb0 [ib_uverbs]__fput+0x94/0x250task_work_run+0x5c/0x90do_exit+0x270/0x4a0do_group_exit+0x2d/0x90get_signal+0x87c/0x8c0arch_do_signal_or_restart+0x25/0x100? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]exit_to_user_mode_loop+0x9c/0x130exit_to_user_mode_prepare+0xb6/0x100syscall_exit_to_user_mode+0x12/0x40do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x1470abe3ec6bCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6bRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470--[ end trace 888a9b92e04c5c97 ]--
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm: call the resume method on internal suspendThere is this reported crash when experimenting with the lvm2 testsuite.The list corruption is caused by the fact that the postsuspend and resumemethods were not paired correctly; there were two consecutive calls to theorigin_postsuspend function. The second call attempts to remove the"hash_list" entry from a list, while it was already removed by the firstcall.Fix __dm_internal_resume so that it calls the preresume and resumemethods of the table's targets.If a preresume method of some target fails, we are in a tricky situation.We can't return an error because dm_internal_resume isn't supposed toreturn errors. We can't return success, because then the "resume" and"postsuspend" methods would not be paired correctly. So, we set theDMF_SUSPENDED flag and we fake normal suspend - it may confuse userspacetools, but it won't cause a kernel crash.------------[ cut here ]------------kernel BUG at lib/list_debug.c:56!invalid opcode: 0000 [#1] PREEMPT SMPCPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffffRBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0Call Trace: ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ? __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4eRIP: 0033:0xf7e6aead---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleaksyzbot identified a kernel information leak vulnerability indo_sys_name_to_handle() and issued the following report [1].[1]"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Bytes 18-19 of 20 are uninitializedMemory access of size 20 starts at ffff888128a46380Data copied to user address 0000000020000240"Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() tosolve the problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: mxs-auart: add spinlock around changing cts stateThe uart_handle_cts_change() function in serial_core expects the callerto hold uport->lock. For example, I have seen the below kernel splat,when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: udc: remove warning when queue disabled epIt is possible trigger below warning message from mass storage function,WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104pc : usb_ep_queue+0x7c/0x104lr : fsg_main_thread+0x494/0x1b3cRoot cause is mass storage function try to queue request from main thread,but other thread may already disable ep when function disable.As there is no function failure in the driver, in order to avoid effortto fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.222.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: check A-MSDU format more carefullyIf it looks like there's another subframe in the A-MSDUbut the header isn't fully there, we can end up readingdata out of bounds, only to discard later. Make this abit more careful and check if the subframe header caneven be present.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: relax socket state check at accept time.Christoph reported the following splat:WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0Modules linked in:CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x4315f9Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002bRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 The reproducer invokes shutdown() before entering the listener status.After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) forTCP_SYN_RECV sockets"), the above causes the child to reach the acceptsyscall in FIN_WAIT1 status.Eric noted we can relax the existing assertion in __inet_accept()
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix memleak in seg6_hmac_init_algoseg6_hmac_init_algo returns without cleaning up the previous allocationsif one fails, so it's going to leak all that memory and the crypto tfms.Update seg6_hmac_exit to only free the memory when allocated, so we canreuse the code directly.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix missing sk_buff release in seg6_input_coreThe seg6_input() function is responsible for adding the SRH into apacket, delegating the operation to the seg6_input_core(). This functionuses the skb_cow_head() to ensure that there is sufficient headroom inthe sk_buff for accommodating the link-layer header.In the event that the skb_cow_header() function fails, theseg6_input_core() catches the error but it does not release the sk_buff,which will result in a memory leak.This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG dueto headroom too small after SRH push") and persists even after commit7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),where the entire seg6_input() code was refactored to deal with netfilterhooks.The proposed patch addresses the identified memory leak by requiring theseg6_input_core() function to release the sk_buff in the event thatskb_cow_head() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: don't walk off the end of a directory data blockThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entryto make sure don't stray beyond valid memory region. Before patching, theloop simply checks that the start offset of the dup and dep is within therange. So in a crafted image, if last entry is xfs_dir2_data_unused, wecan change dup->length to dup->length-1 and leave 1 byte of space. In thenext traversal, this space will be considered as dup or dep. We mayencounter an out of bound read when accessing the fixed members.In the patch, we make sure that the remaining bytes large enough to holdan unused entry before accessing xfs_dir2_data_unused andxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also makesure that the remaining bytes large enough to hold a dirent with asingle-byte name before accessing xfs_dir2_data_entry.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_check_dir_entry()This adds sanity checks for ocfs2_dir_entry to make sure all members ofocfs2_dir_entry don't stray beyond valid memory region.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix sclp_init() cleanup on failureIf sclp_init() fails it only partially cleans up: if there are multiplefailing calls to sclp_init() sclp_state_change_event will be added severaltimes to sclp_reg_list, which results in the following warning:------------[ cut here ]------------list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3...Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30Fix this by removing sclp_state_change_event from sclp_reg_list whensclp_init() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.228.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix quota root leak after quota disable failureIf during the quota disable we fail when cleaning the quota tree or whendeleting the root from the root tree, we jump to the 'out' label withoutever dropping the reference on the quota root, resulting in a leak of theroot since fs_info->quota_root is no longer pointing to the root (we haveset it to NULL just before those steps).Fix this by always doing a btrfs_put_root() call under the 'out' label.This is a problem that exists since qgroups were first added in 2012 bycommit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), butback then we missed a kfree on the quota root and free_extent_buffer()calls on its root and commit root nodes, since back then roots were notyet reference counted.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registersregister store validation for NFT_DATA_VALUE is conditional, however,the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. Thisonly requires a new helper function to infer the register type from theset datatype so this conditional check can be removed. Otherwise,pointer to chain object can be leaked through the registers.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix overflow in get_free_elt()"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.Once it overflows, new elements can still be inserted into the tracing_mapeven though the maximum number of elements (`max_elts`) has been reached.Continuing to insert elements after the overflow could result in thetracing_map containing "tracing_map->max_size" elements, leaving no emptyentries.If any attempt is made to insert an element into a full tracing_map using`__tracing_map_insert()`, it will cause an infinite loop with preemptiondisabled, leading to a CPU hang problem.Fix this by preventing any further increments to "tracing_map->next_elt"once it reaches "tracing_map->max_elt".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: disallow setting special AP channel widthsSetting the AP channel width is meant for use with the normal20/40/... MHz channel width progression, and switching aroundin S1G or narrow channels isn't supported. Disallow that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedNot doing so will make us send a host command to the transport while thefirmware is not alive, which will trigger a WARNING.bad state = 0WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]Call Trace: iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: call cache_put if xdr_reserve_space returns NULLIf not enough buffer space available, but idmap_lookup has triggeredlookup_fn which calls cache_get and returns successfully. Then wemissed to call cache_put here which pairs with cache_get.Reviwed-by: Jeff Layton
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Fix memory leak in management txIn the current logic, memory is allocated for storing the MSDU contextduring management packet TX but this memory is not being freed duringmanagement TX completion. Similar leaks are seen in the management TXcleanup logic.Kmemleak reports this problem as below,unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20Free the memory during completion and cleanup to fix the leak.Protect the mgmt_pending_tx idr_remove() operation inath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar toother instances.Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
Packages affected:
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xen: Fix the issue of resource not being properly released in xenbus_dev_probe()This patch fixes an issue in the function xenbus_dev_probe(). In thexenbus_dev_probe() function, within the if (err) branch at line 313, theprogram incorrectly returns err directly without releasing the resourcesallocated by err = drv->probe(dev, id). As the return value is non-zero,the upper layers assume the processing logic has failed. However, the probeoperation was performed earlier without a corresponding remove operation.Since the probe actually allocates resources, failing to perform the removeoperation could lead to problems.To fix this issue, we followed the resource release logic of thexenbus_dev_remove() function by adding a new block fail_remove before thefail_put block. After entering the branch if (err) at line 313, thefunction will use a goto statement to jump to the fail_remove block,ensuring that the previously acquired resources are correctly released,thus preventing the reference count leak.This bug was identified by an experimental static analysis tool developedby our team. The tool specializes in analyzing reference count operationsand detecting potential issues where resources are not properly managed.In this case, the tool flagged the missing release operation as apotential problem, which led to the development of this patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: remove wrong sb->s_sequence checkJournal emptiness is not determined by sb->s_sequence == 0 but rather bysb->s_start == 0 (which is set a few lines above). Furthermore 0 is avalid transaction ID so the check can spuriously trigger. Remove theinvalid WARN_ON.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kexec: Enable SMT before waking offline CPUsIf SMT is disabled or a partial SMT state is enabled, when a new kernelimage is loaded for kexec, on reboot the following warning is observed:kexec: Waking offline cpu 228.WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc[snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ecThis occurs as add_cpu() fails due to cpu_bootable() returning false forCPUs that fail the cpu_smt_thread_allowed() check or non primarythreads if SMT is disabled.Fix the issue by enabling SMT and resetting the number of SMT threads tothe number of threads per core, before attempting to wake up all presentCPUs.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.65.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.65.1).
-
Description: The demangler in GNU Libiberty allows remote attackers to cause a denial of service (infinite loop, stack overflow, and crash) via a cycle in the references of remembered mangled types.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- crash > 0-0 (version in image is 7.2.1-8.19.2).
-
Description: elfcomm.c in readelf in GNU Binutils 2.29 allows remote attackers to cause a denial of service (excessive memory allocation) or possibly have unspecified other impact via a crafted ELF file that triggers a "buffer overflow on fuzzed archive header," related to an uninitialized variable, an improper conditional jump, and the get_archive_member_name, process_archive_index_and_symbols, and setup_archive functions.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The _bfd_elf_parse_gnu_properties function in elf-properties.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, does not prevent negative pointers, which allows remote attackers to cause a denial of service (out-of-bounds read and application crash) or possibly have unspecified other impact via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: coffgen.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29.1, does not validate the symbol count, which allows remote attackers to cause a denial of service (integer overflow and application crash, or excessive memory allocation) or possibly have unspecified other impact via a crafted PE file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: process_cu_tu_index in dwarf.c in GNU Binutils 2.30 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted binary file, as demonstrated by readelf.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: concat_filename in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted binary file, as demonstrated by nm-new.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The ignore_section_sym function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, does not validate the output_section pointer in the case of a symtab entry with a "SECTION" type that has a "0" value, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted file, as demonstrated by objcopy.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory access exists in _bfd_stab_section_find_nearest_line in syms.c. Attackers could leverage this vulnerability to cause a denial of service (application crash) via a crafted ELF file.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. An invalid memory address dereference was discovered in read_reloc in reloc.c. The vulnerability causes a segmentation fault and application crash, which leads to denial of service, as demonstrated by objdump, because of missing _bfd_clear_contents bounds checking.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in the merge_strings function in merge.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. There is a NULL pointer dereference in _bfd_add_merge_section when attempting to merge sections with large alignments. A specially crafted ELF allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in elf_link_input_bfd in elflink.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31. There is a NULL pointer dereference in elf_link_input_bfd when used for finding STT_TLS symbols without any TLS section. A specially crafted ELF allows remote attackers to cause a denial of service, as demonstrated by ld.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: load_specific_debug_section in objdump.c in GNU Binutils through 2.31.1 contains an integer overflow vulnerability that can trigger a heap-based buffer overflow via a crafted section size.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The parse_die function in dwarf1.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (integer overflow and application crash) via an ELF file with corrupt dwarf1 debug information, as demonstrated by nm.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The swap_std_reloc_in function in aoutx.h in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (aout_32_swap_std_reloc_out NULL pointer dereference and application crash) via a crafted ELF file, as demonstrated by objcopy.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The bfd_section_from_shdr function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (segmentation fault) via a large attribute section.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: An issue was discovered in the Linux kernel before 5.8.10. virt/kvm/kvm_main.c has a kvm_io_bus_unregister_dev memory leak upon a kmalloc failure, aka CID-f65886606c2d.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hamradio: fix memory leak in mkiss_closeMy local syzbot instance hit memory leak inmkiss_open()[1]. The problem was in missingfree_netdev() in mkiss_close().In mkiss_open() netdevice is allocated and thenregistered, but in mkiss_close() netdevice wasonly unregistered, but not freed.Fail log:BUG: memory leakunreferenced object 0xffff8880281ba000 (size 4096): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............ backtrace: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x98/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xaeBUG: memory leakunreferenced object 0xffff8880141a9a00 (size 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@.......... backtrace: [] __hw_addr_create_ex+0x5b/0x310 [] __hw_addr_add_ex+0x1f8/0x2b0 [] dev_addr_init+0x10b/0x1f0 [] alloc_netdev_mqs+0x13b/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xaeBUG: memory leakunreferenced object 0xffff8880219bfc00 (size 512): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x777/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xaeBUG: memory leakunreferenced object 0xffff888029b2b200 (size 256): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x912/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] entry_SYSCALL_64_after_hwframe+0x44/0xae
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix page reclaim for dead peer hairpinWhen adding a hairpin flow, a firmware-side send queue is created forthe peer net device, which claims some host memory pages for itsinternal ring buffer. If the peer net device is removed/unbound beforethe hairpin flow is deleted, then the send queue is not destroyed whichleads to a stack trace on pci device remove:[ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource[ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110[ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0[ 748.002171] ------------[ cut here ]------------[ 748.001177] FW pages counter is 4 after reclaiming all pages[ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core][ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1[ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core][ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9[ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286[ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000[ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51[ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8[ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30[ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000[ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000[ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0[ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 748.001654] Call Trace:[ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core][ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core][ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core][ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core][ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core][ 748.001200] remove_one+0x5f/0xc0 [mlx5_core][ 748.001075] pci_device_remove+0x9f/0x1d0[ 748.000833] device_release_driver_internal+0x1e0/0x490[ 748.001207] unbind_store+0x19f/0x200[ 748.000942] ? sysfs_file_ops+0x170/0x170[ 748.001000] kernfs_fop_write_iter+0x2bc/0x450[ 748.000970] new_sync_write+0x373/0x610[ 748.001124] ? new_sync_read+0x600/0x600[ 748.001057] ? lock_acquire+0x4d6/0x700[ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400[ 748.001126] ? fd_install+0x1c9/0x4d0[ 748.000951] vfs_write+0x4d0/0x800[ 748.000804] ksys_write+0xf9/0x1d0[ 748.000868] ? __x64_sys_read+0xb0/0xb0[ 748.000811] ? filp_open+0x50/0x50[ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50[ 748.001223] do_syscall_64+0x3f/0x80[ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 748.00---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: fix memory leak in rds_recvmsgSyzbot reported memory leak in rds. The problemwas in unputted refcount in case of error.int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, int msg_flags){... if (!rds_next_incoming(rs, &inc)) { ... }After this "if" inc refcount incremented and if (rds_cmsg_recv(inc, msg, rs)) { ret = -EFAULT; goto out; }...out: return ret;}in case of rds_cmsg_recv() fail the refcount won't bedecremented. And it's easy to see from ftrace log, thatrds_inc_addref() don't have rds_inc_put() pair inrds_recvmsg() after rds_cmsg_recv() 1) | rds_recvmsg() { 1) 3.721 us | rds_inc_addref(); 1) 3.853 us | rds_message_inc_copy_to_user(); 1) + 10.395 us | rds_cmsg_recv(); 1) + 34.260 us | }
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix memory leak in netlbl_cipsov4_add_stdReported by syzkaller:BUG: memory leakunreferenced object 0xffff888105df7000 (size 64):comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................backtrace:[<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline][<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline][<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline][<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416[<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739[<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline][<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800[<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504[<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811[<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline][<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340[<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929[<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline][<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674[<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350[<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404[<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433[<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47[<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xaeThe memory of doi_def->map.std pointing is allocated innetlbl_cipsov4_add_std, but no place has freed it. It should befreed in cipso_v4_doi_free which frees the cipso DOI resource.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: fsl_ifc: fix leak of private memory on probe failureOn probe error the driver should free the memory allocated for privatestructure. Fix this by using resource-managed allocation.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:memory: fsl_ifc: fix leak of IO mapping on probe failureOn probe error the driver should unmap the IO memory. Smatch reports: drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: mdio: fix memory leakSyzbot reported memory leak in MDIO bus interface, the problem was inwrong state logic.MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was calledIn case of device_register() has been called we should call put_device()to correctly free the memory allocated for this device, but mdiobus_free()calls just kfree(dev) in case of MDIOBUS_ALLOCATED stateTo avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED_before_ calling device_register(), because put_device() should becalled even in case of device_register() failure.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path ofqla2x00_process_els()"), intended to change: bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN bsg_job->request->msgcode != FC_BSG_RPT_ELSbut changed it to: bsg_job->request->msgcode == FC_BSG_RPT_ELSinstead.Change the == to a != to avoid leaking the fcport structure or freeingunallocated memory.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) andthe number of it's interfaces less than 4, an out-of-bounds read bug occurswhen parsing the interface descriptor for this device.Fix this by checking the number of interfaces.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()for_each_pci_dev() is implemented by pci_get_device(). The comment ofpci_get_device() says that it will increase the reference count for thereturned pci_dev and also decrease the reference count for the inputpci_dev @from if it is not NULL.If we break for_each_pci_dev() loop with pdev not NULL, we need to callpci_dev_put() to decrease the reference count. Add the missingpci_dev_put() for the error path to avoid reference count leak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: Fix a potential socket leak in p9_socket_openBoth p9_fd_create_tcp() and p9_fd_create_unix() will callp9_socket_open(). If the creation of p9_trans_fd fails,p9_fd_create_tcp() and p9_fd_create_unix() will return anerror directly instead of releasing the cscoket, which willresult in a socket leak.This patch adds sock_release() to fix the leak issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence objThis issue takes place in an error path inamdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls intodefault case, the function simply returns -EINVAL, forgetting todecrement the reference count of a dma_fence obj, which is bumpedearlier by amdgpu_cs_get_fence(). This may result in reference countleaks.Fix it by decreasing the refcount of specific object before returningthe error code.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix premature hw access after PCI errorAfter a recoverable PCI error has been detected and recovered, qla driverneeds to check to see if the error condition still persist and/or waitfor the OS to give the resume signal.Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60[qla2xxx]Sep 8 22:26:03 localhost kernel: Call Trace:Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160[qla2xxx]Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120[qla2xxx]Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360..Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCIdisconnect.Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013hSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable tocapture FW dumpSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,waited 5221 msecsSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmioenabled returning.Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBXCommand timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5mb[0-3]=[0xffff 0xffff 0xffff 0xffff]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJTThere is a potential memory leak in lpfc_ignore_els_cmpl() andlpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT(lpfc_rcv_plogi()'s login_mbox).Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(),and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf forservice parameters.For lpfc_els_rsp_reject() failure, free both the ctx_buf for serviceparameters and the login_mbox.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sfp: fix memory leak in sfp_probe()sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). Whendevm_add_action() fails, sfp is not freed, which leads to a memory leak.We should use devm_add_action_or_reset() instead of devm_add_action().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix possible refcount leak in tipc_sk_create()Free sk in case tipc_sk_insert() fails.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferredSimilar to the handling of play_deferred in commit 19cfe912c37b("Bluetooth: btusb: Fix memory leak in play_deferred"), we thoughta patch might be needed here as well.Currently usb_submit_urb is called directly to submit deferred txurbs after unanchor them.So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urband cause memory leak.Put those urbs in tx_anchor to avoid the leak, and also fix the errorhandling.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix small mempool leak in SMB2_negotiate()In some cases of failure (dialect mismatches) in SMB2_negotiate(), afterthe request is sent, the checks would return -EIO when they should berather setting rc = -EIO and jumping to neg_exit to free the responsebuffer from mempool.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix refcount bug in sk_psock_get (2)Syzkaller reports refcount bug as follows:------------[ cut here ]------------refcount_t: saturated; leaking memory.WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19Modules linked in:CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel willreplaces TCP with SMC. In order to forward wakeupsmc socket waitqueue after fallback, kernel will setsclcsk->sk_user_data to origin smc socket insmc_fback_replace_callbacks().Later, in shutdown syscall, kernel will callssk_psock_get(), which treats the clcsk->sk_user_dataas psock type, triggering the refcnt warning.So, the root cause is that smc and psock, both will usesk_user_data field. So they will mismatch this fieldeasily.This patch solves it by using another bit(defined asSK_USER_DATA_PSOCK) in PTRMASK, to mark whethersk_user_data points to a psock object or not.This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e("net, sk_msg: Clear sk_user_data pointer on clone if tagged").For there will possibly be more flags in the sk_user_data field,this patch also refactor sk_user_data flags code to be more genericto improve its maintainability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix a memory leak in an error handling pathA bitmap_zalloc() must be balanced by a corresponding bitmap_free() in theerror handling path of afu_allocate_irqs().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix memory leak when build ntlmssp negotiate blob failedThere is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000060609a61>] mempool_alloc+0xe1/0x260 [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60 [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460 [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0 [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410 [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0 [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0 [<000000006cbc43d9>] mount_get_conns+0x7a/0x730 [<000000005922d816>] cifs_mount+0x103/0xd10 [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90 [<0000000078034979>] smb3_get_tree+0x1d5/0x300 [<000000004371f980>] vfs_get_tree+0x41/0xf0 [<00000000b670d8a7>] path_mount+0x9b3/0xdd0 [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0 [<000000009404c3b9>] do_syscall_64+0x35/0x80When build ntlmssp negotiate blob failed, the session setup requestshould be freed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: fix possible memory leak in snd_ac97_dev_register()If device_register() fails in snd_ac97_dev_register(), it shouldcall put_device() to give up reference, or the name allocated indev_set_name() is leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix xid leak in cifs_flock()If not flock, before return -ENOLCK, should free the xid,otherwise, the xid will be leaked.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()As the comment of pci_get_domain_bus_and_slot() says, it returnsa PCI device with refcount incremented, so it doesn't need tocall an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCIdevice needs to be put in the error path.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:acct: fix potential integer overflow in encode_comp_t()The integer overflow is descripted with following codes: > 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 }Currently comp_t is defined as type of '__u16', but the variable 'exp' istype of 'int', so overflow would happen when variable 'exp' in line 343 isgreater than 65535.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:configfs: fix possible memory leak in configfs_create_dir()kmemleak reported memory leaks in configfs_create_dir():unreferenced object 0xffff888009f6af00 (size 192): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ...unreferenced object 0xffff888003ba7180 (size 96): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ...This is because the refcount is not correct in configfs_make_dirent().For normal stage, the refcount is changing as:configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2...configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ... *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, releaseHowever, if we failed in configfs_create():configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode);There is no inode in the error path, so the configfs_d_iput() is lostand makes sd and fragment memory leaked.To fix this, when we failed in configfs_create(), manually callconfigfs_put(sd) to keep the refcount correct.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
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:
- libncurses5 < 5.9-88.1 (version in image is 5.9-81.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()There is a memory leaks problem reported by kmemleak:unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes):ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace:[] __kmalloc+0x4d/0x150[] ubi_eba_create_table+0x76/0x170 [ubi][] ubi_resize_volume+0x1be/0xbc0 [ubi][] ubi_cdev_ioctl+0x701/0x1850 [ubi][] __x64_sys_ioctl+0x11d/0x170[] do_syscall_64+0x35/0x80[] entry_SYSCALL_64_after_hwframe+0x46/0xb0This is due to a mismatch between create and destroy interfaces, andin detail that "new_eba_tbl" created by ubi_eba_create_table() butdestroyed by kfree(), while will causing "new_eba_tbl->entries" notfreed.Fix it by replacing kfree(new_eba_tbl) withubi_eba_destroy_table(new_eba_tbl)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/mdp5: Don't leak some plane stateApparently no one noticed that mdp5 plane states leak like a sieveever since we introduced plane_state->commit refcount a few years agoin 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state tooearly by tracking commits, v3.")Fix it by using the right helpers.Patchwork: https://patchwork.freedesktop.org/patch/551236/
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: free iio for atombios when driver shutdownFix below kmemleak when unload radeon driver:unreferenced object 0xffff9f8608ede200 (size 512): comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] really_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach+0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0iio was allocated in atom_index_iio() called by atom_parse(),but it doesn't got released when the dirver is shutdown.Fix this kmemleak by free it in radeon_atombios_fini().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:udf: Do not bother merging very long extentsWhen merging very long extents we try to push as much length as possibleto the first extent. However this is unnecessarily complicated and notreally worth the trouble. Furthermore there was a bug in the logicresulting in corrupting extents in the file as syzbot reproducer shows.So just don't bother with the merging of extents that are too longtogether.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix a memory leakAdd a forgotten kfree().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix leak in devfreq_dev_release()srcu_init_notifier_head() allocates resources that need to be releasedwith a srcu_cleanup_notifier_head() call.Reported by kmemleak.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()A fix for:BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013When edev->components is zero, accessing edev->component[0] members iswrong.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm: amd: display: Fix memory leakageThis commit fixes memory leakage in dc_construct_ctx() function.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tun: Fix memory leak for detached NAPI queue.syzkaller reported [0] memory leaks of sk and skb related to the TUNdevice with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun);If we enable NAPI and multi-queue on a TUN device, we can put skb intotfile->sk.sk_write_queue after the queue is detached. We should preventit by checking tfile->detached before queuing skb.Note this must be done under tfile->sk.sk_write_queue.lock because write()and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there wouldbe a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb)Another solution is to call tun_queue_purge() when closing andreattaching the detached queue, but it could paper over anotherproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.[0]:unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdcunreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [<---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clkWhen the best clk is searched, we iterate over all possible clk.If we find a better match, the previous one, if any, needs to be freed.If a better match has already been found, we still need to free the newone, otherwise it leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probeSmatch reports:drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.timer_baseaddr may have the problem of not being released after use,I replaced it with the devm_of_iomap() function and added the clk_put()function to cleanup the "clk_ce" and "clk_cs".
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knodeWhen u32_replace_hw_knode fails, we need to undo the tcf_bind_filteroperation done at u32_set_parms.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: safexcel - Cleanup ring IRQ workqueues on load failureA failure loading the safexcel driver results in the following warningon boot, because the IRQ affinity has not been correctly cleaned up.Ensure we clean up the affinity and workqueues on a failure to load thedriver.crypto-safexcel: probe of f2800000.crypto failed with error -2------------[ cut here ]------------WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3Hardware name: MikroTik RB5009 (DT)pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : free_irq+0x300/0x340lr : free_irq+0x2e0/0x340sp : ffff800008fa3890x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5ex14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0Call trace: free_irq+0x300/0x340 devm_irq_release+0x14/0x20 devres_release_all+0xa0/0x100 device_unbind_cleanup+0x14/0x60 really_probe+0x198/0x2d4 __driver_probe_device+0x74/0xdc driver_probe_device+0x3c/0x110 __driver_attach+0x8c/0x190 bus_for_each_dev+0x6c/0xc0 driver_attach+0x20/0x30 bus_add_driver+0x148/0x1fc driver_register+0x74/0x120 __platform_driver_register+0x24/0x30 safexcel_init+0x48/0x1000 [crypto_safexcel] do_one_initcall+0x4c/0x1b0 do_init_module+0x44/0x1cc load_module+0x1724/0x1be4 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x1c/0x24 invoke_syscall+0x44/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x20/0x80 el0_svc+0x14/0x4c el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x148/0x14c---[ end trace 0000000000000000 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle case when repair happens with dev-replace[BUG]There is a bug report that a BUG_ON() in btrfs_repair_io_failure()(originally repair_io_failure() in v6.0 kernel) got triggered whenreplacing a unreliable disk: BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3 kernel BUG at fs/btrfs/extent_io.c:2380! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2 Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs] Call Trace: clean_io_failure+0x14d/0x180 [btrfs] end_bio_extent_readpage+0x412/0x6e0 [btrfs] ? __switch_to+0x106/0x420 process_one_work+0x1c7/0x380 worker_thread+0x4d/0x380 ? rescuer_thread+0x3a0/0x3a0 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30[CAUSE]Before the BUG_ON(), we got some read errors from the replace targetfirst, note the mirror number (3, which is beyond RAID1 duplication,thus it's read from the replace target device).Then at the BUG_ON() location, we are trying to writeback the repairedsectors back the failed device.The check looks like this: ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical, &map_length, &bioc, mirror_num); if (ret) goto out_counter_dec; BUG_ON(mirror_num != bioc->mirror_num);But inside btrfs_map_block(), we can modify bioc->mirror_num especiallyfor dev-replace: if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 && !need_full_stripe(op) && dev_replace->tgtdev != NULL) { ret = get_extra_mirror_from_replace(fs_info, logical, *length, dev_replace->srcdev->devid, &mirror_num, &physical_to_patch_in_first_stripe); patch_the_first_stripe_for_dev_replace = 1; }Thus if we're repairing the replace target device, we're going totrigger that BUG_ON().But in reality, the read failure from the replace target device may bethat, our replace hasn't reached the range we're reading, thus we'rereading garbage, but with replace running, the range would be properlyfilled later.Thus in that case, we don't need to do anything but let the replaceroutine to handle it.[FIX]Instead of a BUG_ON(), just skip the repair if we're repairing thedevice replace target device.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: tuners: qt1010: replace BUG_ON with a regular errorBUG_ON is unnecessary here, and in addition it confuses smatch.Replacing this with an error return help resolve this smatchwarning:drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.194.1 (version in image is 4.12.14-122.179.1).
-
Description: Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSLto crash leading to a potential Denial of Service attackImpact summary: Applications loading files in the PKCS12 format from untrustedsources might terminate abruptly.A file in PKCS12 format can contain certificates and keys and may come from anuntrusted source. The PKCS12 specification allows certain fields to be NULL, butOpenSSL does not correctly check for this case. This can lead to a NULL pointerdereference that results in OpenSSL crashing. If an application processes PKCS12files from an untrusted source using the OpenSSL APIs then that application willbe vulnerable to this issue.OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()and PKCS12_newpass().We have also fixed a similar issue in SMIME_write_PKCS7(). However since thisfunction is related to writing data we do not consider it security significant.The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.
Packages affected:
- libopenssl1_0_0 < 1.0.2p-3.90.1 (version in image is 1.0.2p-3.84.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix a memleak in init_credit_returnWhen dma_alloc_coherent fails to allocate dd->cr_base[i].va,init_credit_return should deallocate dd->cr_base anddd->cr_base[i] that allocated before. Or those resourceswould be never freed and a memleak is triggered.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cachefiles: fix memory leak in cachefiles_add_cache()The following memory leak was reported after unbinding /dev/cachefiles:==================================================================unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [] kmem_cache_alloc+0x2d5/0x370 [] prepare_creds+0x26/0x2e0 [] cachefiles_determine_cache_security+0x1f/0x120 [] cachefiles_add_cache+0x13c/0x3a0 [] cachefiles_daemon_write+0x146/0x1c0 [] vfs_write+0xcb/0x520 [] ksys_write+0x69/0xf0 [] do_syscall_64+0x72/0x140 [] entry_SYSCALL_64_after_hwframe+0x6e/0x76==================================================================Put the reference count of cache_cred in cachefiles_daemon_unbind() tofix the problem. And also put cache_cred in cachefiles_add_cache() errorbranch to avoid memory leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.
Packages affected:
- libxml2-2 < 2.9.4-46.75.1 (version in image is 2.9.4-46.65.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: us122l: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.The loop of us122l->mmap_count check is dropped as well. The check isuseless for the asynchronous operation with *_when_closed().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usx2y: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix memory leak in dccp_feat_change_recvIf dccp_feat_push_confirm() fails after new value for SP feature was acceptedwithout reconciliation ('entry == NULL' branch), memory allocated for that valuewith dccp_feat_clone_sp_val() is never freed.Here is the kmemleak stack for this:unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1Clean up the allocated memory in case of dccp_feat_push_confirm() failureand bail out with an error reset code.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- iproute2 > 0-0 (version in image is 4.12-16.6.1).
-
Description: When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- glibc < 2.22-114.40.1 (version in image is 2.22-114.31.1).
-
Description: A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be exploited.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libpcap1 > 0-0 (version in image is 1.8.1-10.3.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- augeas > 0-0 (version in image is 1.10.1-4.3.2).
-
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: Fix unsafe attribute parsing in output_userspace()This patch replaces the manual Netlink attribute iteration inoutput_userspace() with nla_for_each_nested(), which ensures that onlywell-formed attributes are processed.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold the array of `struct comedi_insn`, getting the length from the`n_insns` member of the `struct comedi_insnlist` supplied by the user.The allocation will fail with a WARNING and a stack dump if it is toolarge.Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`value is unreasonable.Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Exit early on perf_mmap() failWhen perf_mmap() fails to allocate a buffer, it still invokes theevent_mapped() callback of the related event. On X86 this might increasethe perf_rdpmc_allowed reference counter. But nothing undoes this asperf_mmap_close() is never called in this case, which causes anotherreference count leak.Return early on failure to prevent that.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Fix surprise plug detection and recoveryThe existing PowerNV hotplug code did not handle surprise plug eventscorrectly, leading to a complete failure of the hotplug system after deviceremoval and a required reboot to detect new devices.This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot.Issue the appropriate unfreeze and rescan commands on hotplug events,and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.[bhelgaas: tidy comments]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add max boundary check for VF filtersThere is no check for max filters that VF can request. Add it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.280.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- gettext-runtime > 0-0 (version in image is 0.19.2-3.3.6).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl > 0-0 (version in image is 8.0.1-11.74.1).
-
Description: A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libssh4 > 0-0 (version in image is 0.8.7-3.9.1).
-
Description: Modules/_pickle.c in Python before 3.7.1 has an integer overflow via a large LONG_BINPUT value that is mishandled during a "resize to twice the size" attempt. This issue might cause memory exhaustion, but is only relevant if the pickle format is used for serializing tens or hundreds of gigabytes of data. This issue is fixed in: v3.4.10, v3.4.10rc1; v3.5.10, v3.5.10rc1, v3.5.7, v3.5.7rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12, v3.6.7, v3.6.7rc1, v3.6.7rc2, v3.6.8, v3.6.8rc1, v3.6.9, v3.6.9rc1; v3.7.1, v3.7.1rc1, v3.7.1rc2, v3.7.2, v3.7.2rc1, v3.7.3, v3.7.3rc1, v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1, v3.7.8, v3.7.8rc1, v3.7.9.
Packages affected:
- python3 > 0-0 (version in image is 3.4.10-25.116.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libxml2-2 > 0-0 (version in image is 2.9.4-46.65.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: emux: improve patch ioctl data validationIn load_data(), make the validation of and skipping over the main infoblock match that in load_guspatch().In load_guspatch(), add checking that the specified patch length matchesthe actually supplied data, like load_data() already did.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In GNU tar before 1.35, mishandled extension attributes in a PAX archive can lead to an application crash in xheader.c.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- tar < 1.27.1-15.24.1 (version in image is 1.27.1-15.21.1).
-
Description: Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause anoverflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values largerthan MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.0111-17.29.1 (version in image is 9.0.1894-17.23.2).
-
Description: Vim is an open source command line text editor. double-free in dialog_changed() in Vim < v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim < 9.1.1406-17.48.1 (version in image is 9.0.1894-17.23.2).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- vim > 0-0 (version in image is 9.0.1894-17.23.2).
-
Description: In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- gpg2 > 0-0 (version in image is 2.0.24-9.14.1).
-
Description: There is a LOW severity vulnerability affecting CPython, specifically the'http.cookies' standard library module.When parsing cookies that contained backslashes for quoted characters inthe cookie value, the parser would use an algorithm with quadraticcomplexity, resulting in excess CPU resources being used while parsing thevalue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
Packages affected:
- python3-urllib3 > 0-0 (version in image is 1.25.10-3.34.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: appletouch - initialize work before device registrationSyzbot has reported warning in __flush_work(). This warning is caused bywork->func == NULL, which means missing work initialization.This may happen, since input_dev->close() callscancel_work_sync(&dev->work), but dev->work initalization happens _after_input_register_device() call.So this patch moves dev->work initialization before registering inputdevice
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix igb_down hung on surprise removalIn a setup where a Thunderbolt hub connects to Ethernet and a displaythrough USB Type-C, users may experience a hung task timeout when theyremove the cable between the PC and the Thunderbolt hub.This is because the igb_down function is called multiple times whenthe Thunderbolt hub is unplugged. For example, the igb_io_error_detectedtriggers the first call, and the igb_remove triggers the second call.The second call to igb_down will block at napi_synchronize.Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30In this case, igb_io_error_detected detaches the network interfaceand requests a PCIE slot reset, however, the PCIE reset callback isnot being invoked and thus the Ethernet connection breaks down.As the PCIE error in this case is a non-fatal one, requesting aslot reset can be avoided.This patch fixes the task hung issue and preserves Ethernetconnection by ignoring non-fatal PCIE errors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix data-races around sysctl_net_busy_readWe need to protect the reader reading the sysctl value because thevalue can be changed concurrently.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()Many syzbot reports show extreme rtnl pressure, and many of them hintthat smc acquires rtnl in netns creation for no good reason [1]This patch returns early from smc_pnet_net_init()if there is no netdevice yet.I am not even sure why smc_pnet_create_pnetids_list() even exists,because smc_pnet_netdev_event() is also callingsmc_pnet_add_base_pnetid() when handling NETDEV_UP event.[1] extract of typical syzbot reports2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:8782 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races in unix_release_sock/unix_stream_sendmsgA data-race condition has been identified in af_unix. In one data path,the write function unix_release_sock() atomically writes tosk->sk_shutdown using WRITE_ONCE. However, on the reader side,unix_stream_sendmsg() does not read it atomically. Consequently, thisissue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")addressed a comparable issue in the past regarding sk->sk_shutdown.However, it overlooked resolving this particular data path.This patch only offending unix_stream_sendmsg() function, since theother reads seem to be protected by unix_state_lock() as discussed in
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: put dl_stid if fail to queue dl_recallBefore calling nfsd4_run_cb to queue dl_recall to the callback_wq, weincrement the reference count of dl_stid.We expect that after the corresponding work_struct is processed, thereference count of dl_stid will be decremented through the callbackfunction nfsd4_cb_recall_release.However, if the call to nfsd4_run_cb fails, the incremented referencecount of dl_stid will not be decremented correspondingly, leading to thefollowing nfs4_stid leak:unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid iffail to queue dl_recall.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: st: Fix array overflow in st_setup()Change the array size to follow parms size instead of a fixed value.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (integer underflow or overflow, and application crash) via an ELF file with a corrupt DWARF FORM block, as demonstrated by nm.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: The assign_file_positions_for_non_load_sections function in elf.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an ELF file with a RELRO segment that lacks a matching LOAD segment, as demonstrated by objcopy.
Packages affected:
- libctf-nobfd0 > 0-0 (version in image is 2.41-9.53.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "Revert "block, bfq: honor already-setup queue merges""A crash [1] happened to be triggered in conjunction with commit2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). Thelatter was then reverted by commit ebc69e897e17 ("Revert "block, bfq:honor already-setup queue merges""). Yet, the reverted commit was notthe one introducing the bug. In fact, it actually triggered a UAFintroduced by a different commit, and now fixed by commit d29bd41428cf("block, bfq: reset last_bfqq_created on group change").So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq:honor already-setup queue merges") out. This commit restores it.[1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Under some circumstances, this weakness allows a user who has access to run the "ps" utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libprocps3 < 3.3.9-11.33.1 (version in image is 3.3.9-11.27.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: reduce WARN to dev_dbg() in callbackThe warn is triggered on a known race condition, documented in the code abovethe test, that is correctly handled. Using WARN() hinders automated testing.Reducing severity.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: clear PARENT_WATCHED flags lazilyIn some setups directories can have many (usually negative) dentries.Hence __fsnotify_update_child_dentry_flags() function can take asignificant amount of time. Since the bulk of this function happensunder inode->i_lock this causes a significant contention on the lockwhen we remove the watch from the directory as the__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()races with __fsnotify_update_child_dentry_flags() calls from__fsnotify_parent() happening on children. This can lead upto softlockupreports reported by users.Fix the problem by calling fsnotify_update_children_dentry_flags() toset PARENT_WATCHED flags only when parent starts watching children.When parent stops watching children, clear false positive PARENT_WATCHEDflags lazily in __fsnotify_parent() for each accessed child.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/ipv6: release expired exception dst cached in socketDst objects get leaked in ip6_negative_advice() when this function isexecuted for an expired IPv6 route located in the exception table. Thereare several conditions that must be fulfilled for the leak to occur:* an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created* a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions* after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dstWhen TCP executes ip6_negative_advice() for an exception dst that hasexpired and if no other socket holds a reference to the exception dst, therefcount of the exception dst is 2, which corresponds to the incrementmade by dst_init() and the increment made by the TCP socket for which theconnection is timing out. The refcount made by the socket is neverreleased. The refcount of the dst is decremented in sk_dst_reset() butthat decrement is counteracted by a dst_hold() intentionally placed justbefore the sk_dst_reset() in ip6_negative_advice(). Afterip6_negative_advice() has finished, there is no other object tied to thedst. The socket lost its reference stored in sk_dst_cache and the dst isno longer in the exception table. The exception dst becomes a leakedobject.As a result of this dst leak, an unbalanced refcount is reported for theloopback device of a net namespace being destroyed under kernels that donot contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):unregister_netdevice: waiting for lo to become free. Usage count = 2Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). Thepatch that introduced the dst_hold() in ip6_negative_advice() was92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22merely refactored the code with regards to the dst refcount so the issuewas present even before 92f1655aa2b22. The bug was introduced in54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actuallyexpired.") where the expired cached route is deleted and the sk_dst_cachemember of the socket is set to NULL by calling dst_negative_advice() butthe refcount belonging to the socket is left unbalanced.The IPv4 version - ipv4_negative_advice() - is not affected by this bug.When the TCP connection times out ipv4_negative_advice() merely resets thesk_dst_cache of the socket while decrementing the refcount of theexception dst.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.247.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: separate no-async decryption request handling from asyncIf we're not doing async, the handling is much simpler. There's noreference counting, we just need to wait for the completion to wake usup and return its result.We should preferably also use a separate crypto_wait. I'm not seeing aUAF as I did in the past, I think aec7961916f3 ("tls: fix race betweenasync notify and socket close") took care of it.This will make the next fix easier.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: socket: Lookup orig tuple for IPv6 SNATnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets torestore the original 5-tuple in case of SNAT, to be able to find theright socket (if any). Then socket_match() can correctly check whetherthe socket was transparent.However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks thisconntrack lookup, making xt_socket fail to match on the socket when thepacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, aspods' addresses are in the fd00::/8 ULA subnet and need to be replacedwith the node's external address. Cilium leverages Envoy to enforce L7policies, and Envoy uses transparent sockets. Cilium inserts an iptablesprerouting rule that matches on `-m socket --transparent` and redirectsthe packets to localhost, but it fails to match SNATed IPv6 packets dueto that missing conntrack lookup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: bpf: Only mitigate cBPF programs loaded by unprivileged usersSupport for eBPF programs loaded by unprivileged users is typicallydisabled. This means only cBPF programs need to be mitigated for BHB.In addition, only mitigate cBPF programs that were loaded by anunprivileged user. Privileged users can also load the same programvia eBPF, making the mitigation pointless.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock... or we risk stealing final mntput from sync umount - raising mnt_countafter umount(2) has verified that victim is not busy, but before ithas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't seethat it's safe to quietly undo mnt_count increment and leaves droppingthe reference to caller, where it'll be a full-blown mntput().Check under mount_lock is needed; leaving the current one done beforetaking that makes no sense - it's nowhere near common enough to botherwith.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.269.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()Update struct hid_descriptor to better reflect the mandatory andoptional parts of the HID Descriptor as per USB HID 1.11 specification.Note: the kernel currently does not parse any optional HID classdescriptors, only the mandatory report descriptor.Update all references to member element desc[0] to rpt_desc.Add test to verify bLength and bNumDescriptors values are valid.Replace the for loop with direct access to the mandatory HID classdescriptor member for the report descriptor. This eliminates thepossibility of getting an out-of-bounds fault.Add a warning message if the HID descriptor contains any unsupportedoptional HID class descriptors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.272.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python > 0-0 (version in image is 2.7.18-33.26.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Return correct error code from smb2_get_enc_keyAvoid a warning if the error percolates back up:[440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key[440700.386947] ------------[ cut here ]------------[440700.386948] err = 1[440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70...[440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu...[440700.397334] Call Trace:[440700.397346] __filemap_set_wb_err+0x1a/0x70[440700.397419] cifs_writepages+0x9c7/0xb30 [cifs][440700.397426] do_writepages+0x4b/0xe0[440700.397444] __filemap_fdatawrite_range+0xcb/0x100[440700.397455] filemap_write_and_wait+0x42/0xa0[440700.397486] cifs_setattr+0x68b/0xf30 [cifs][440700.397493] notify_change+0x358/0x4a0[440700.397500] utimes_common+0xe9/0x1c0[440700.397510] do_utimes+0xc5/0x150[440700.397520] __x64_sys_utimensat+0x88/0xd0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: qcom: Put child node before returnPut child node before return to fix potential reference count leak.Generally, the reference count of child is incremented and decrementedautomatically in the macro for_each_available_child_of_node() and shouldbe decremented manually if the loop is broken in loop body.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.201.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()When insert and remove the orangefs module, there are memory leakedas below:unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0Use the golbal variable as the buffer rather than dynamic allocate toslove the problem.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (adc128d818) Fix underflows seen when writing limit attributesDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a largenegative number such as -9223372036854775808 is provided by the user.Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: hyperv_fb: Allow graceful removal of framebufferWhen a Hyper-V framebuffer device is unbind, hyperv_fb driver tries torelease the framebuffer forcefully. If this framebuffer is in use itproduce the following WARN and hence this framebuffer is never released.[ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40< snip >[ 44.111289] Call Trace:[ 44.111290] [ 44.111291] ? show_regs+0x6c/0x80[ 44.111295] ? __warn+0x8d/0x150[ 44.111298] ? framebuffer_release+0x2c/0x40[ 44.111300] ? report_bug+0x182/0x1b0[ 44.111303] ? handle_bug+0x6e/0xb0[ 44.111306] ? exc_invalid_op+0x18/0x80[ 44.111308] ? asm_exc_invalid_op+0x1b/0x20[ 44.111311] ? framebuffer_release+0x2c/0x40[ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb][ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus][ 44.111323] device_remove+0x40/0x80[ 44.111325] device_release_driver_internal+0x20b/0x270[ 44.111327] ? bus_find_device+0xb3/0xf0Fix this by moving the release of framebuffer and assosiated memoryto fb_ops.fb_destroy function, so that framebuffer framework handlesit gracefully.While we fix this, also replace manual registrations/unregistration offramebuffer with devm_register_framebuffer.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kexec: fix memory leak of elf header bufferThis is reported by kmemleak detector:unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xaeIn crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() tostore elf headers. While it's not freed back to system correctly whenkdump kernel is reloaded or unloaded. Then memory leak is caused. Fix itby introducing x86 specific function arch_kimage_file_post_load_cleanup(),and freeing the buffer there.And also remove the incorrect elf header buffer freeing code. Beforecalling arch specific kexec_file loading function, the image instance hasbeen initialized. So 'image->elf_headers' must be NULL. It doesn't makesense to free the elf header buffer in the place.Three different people have reported three bugs about the memory leak onx86_64 inside Redhat.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix possible memleak when register 'hctx' failedThere's issue as follows when do fault injection test:unreferenced object 0xffff888132a9f400 (size 512): comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2.... 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0 [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230 [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910 [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0 [<00000000a2a34657>] 0xffffffffa2ad310f [<00000000b173f718>] 0xffffffffa2af824a [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0 [<00000000f32fdf93>] do_init_module+0xdf/0x320 [<00000000cbe8541e>] load_module+0x3006/0x3390 [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0Fault injection context as follows: kobject_add blk_mq_register_hctx blk_mq_sysfs_register blk_register_queue device_add_disk null_add_dev.part.0 [null_blk]As 'blk_mq_register_hctx' may already add some objects when failed halfway,but there isn't do fallback, caller don't know which objects add failed.To solve above issue just do fallback when add objects failed halfway in'blk_mq_register_hctx'.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: amba-pl011: avoid SBSA UART accessing DMACR registerChapter "B Generic UART" in "ARM Server Base System Architecture" [1]documentation describes a generic UART interface. Such generic UARTdoes not support DMA. In current code, sbsa_uart_pops andamba_pl011_pops share the same stop_rx operation, which will invokepl011_dma_rx_stop, leading to an access of the DMACR register. Thiscommit adds a using_rx_dma check in pl011_dma_rx_stop to avoid theaccess to DMACR register for SBSA UARTs which does not support DMA.When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", LinuxSBSA PL011 driver will access PL011 DMACR register in some functions.For most real SBSA Pl011 hardware implementations, the DMACR writebehaviour will be ignored. So these DMACR operations will not causeobvious problems. But for some virtual SBSA PL011 hardware, like Xenvirtual SBSA PL011 (vpl011) device, the behaviour might be different.Xen vpl011 emulation will inject a data abort to guest, when guest isaccessing an unimplemented UART register. As Xen VPL011 is SBSAcompatible, it will not implement DMACR register. So when Linux SBSAPL011 driver access DMACR register, it will get an unhandled data abortfault and the application will get a segmentation fault:Unhandled fault at 0xffffffc00944d048Mem abort info: ESR = 0x96000000 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x00: ttbr address size faultData abort info: ISV = 0, ISS = 0x00000000 CM = 0, WnR = 0swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000[ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP...Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4Code: b9000083 b901f001 794038a0 8b000042 (b9000041)---[ end trace 83dd93df15c3216f ]---note: bootlogd[132] exited with preempt_count 1/etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemonThis has been discussed in the Xen community, and we think it should fixthis in Linux. See [2] for more information.[1] https://developer.arm.com/documentation/den0094/c/?lang=en[2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:char: tpm: Protect tpm_pm_suspend with locksCurrently tpm transactions are executed unconditionally intpm_pm_suspend() function, which may lead to races with other tpmaccessors in the system.Specifically, the hw_random tpm driver makes use of tpm_get_random(),and this function is called in a loop from a kthread, which means it'snot frozen alongside userspace, and so can race with the work doneduring system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350Fix this by calling tpm_try_get_ops(), which itself is a wrapper aroundtpm_chip_start(), but takes the appropriate mutex.[Jason: reworked commit message, added metadata]
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.234.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid0, raid10: Don't set discard sectors for request queueIt should use disk_stack_limits to get a proper max_discard_sectorsrather than setting a value by stack drivers.And there is a bug. If all member disks are rotational devices,raid0/raid10 set max_discard_sectors. So the member devices arenot ssd/nvme, but raid0/raid10 export the wrong value. It reportswarning messages in function __blkdev_issue_discard when mkfs.xfslike this:[ 4616.022599] ------------[ cut here ]------------[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0[ 4616.236689] Call Trace:[ 4616.239428] blkdev_issue_discard+0x52/0xb0[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00[ 4616.248883] blkdev_ioctl+0x116/0x280[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0[ 4616.257163] do_syscall_64+0x5c/0x90[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690[ 4616.270527] ? do_syscall_64+0x69/0x90[ 4616.274717] ? exc_page_fault+0x62/0x150[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 4616.284748] RIP: 0033:0x7f9a55398c6b
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Use of Hardware Page Aggregation (HPA) and Stage-1 and/or Stage-2 translation on Cortex-A77, Cortex-A78, Cortex-A78C, Cortex-A78AE, Cortex-A710, Cortex-X1, Cortex-X1C, Cortex-X2, Cortex-X3, Cortex-X4, Cortex-X925, Neoverse V1, Neoverse V2, Neoverse V3, Neoverse V3AE, Neoverse N2 may permit bypass of Stage-2 translation and/or GPT protection.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: ISC BIND 9.7.1 through 9.7.2-P3, when configured as an authoritative server, allows remote attackers to cause a denial of service (deadlock and daemon hang) by sending a query at the time of (1) an IXFR transfer or (2) a DDNS update.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: ISC BIND 9.8.x through 9.8.4-P1 and 9.9.x through 9.9.2-P1, in certain configurations involving DNS64 with a Response Policy Zone that lacks an AAAA rewrite rule, allows remote attackers to cause a denial of service (assertion failure and named daemon exit) via a query for an AAAA record.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: libdns in ISC BIND 9.7.x and 9.8.x before 9.8.4-P2, 9.8.5 before 9.8.5b2, 9.9.x before 9.9.2-P2, and 9.9.3 before 9.9.3b2 on UNIX platforms allows remote attackers to cause a denial of service (memory consumption) via a crafted regular expression, as demonstrated by a memory-exhaustion attack against a machine running a named process.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: ISC BIND 9.0.x through 9.8.x, 9.9.0 through 9.9.6, and 9.10.0 through 9.10.1 does not limit delegation chaining, which allows remote attackers to cause a denial of service (memory consumption and named crash) via a large or infinite number of referrals.
Packages affected:
- libbind9-161 > 0-0 (version in image is 9.11.22-3.49.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2015-7703. Reason: This candidate is a reservation duplicate of CVE-2015-7703. Notes: All CVE users should reference CVE-2015-7703 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- ntp > 0-0 (version in image is 4.2.8p17-103.1).
-
Description: Race condition in resolver.c in named in ISC BIND 9.9.8 before 9.9.8-P2 and 9.10.3 before 9.10.3-P2 allows remote attackers to cause a denial of service (INSIST assertion failure and daemon exit) via unspecified vectors.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- bind-utils > 0-0 (version in image is 9.11.22-3.49.1).
-
Description: The big2_toUtf8 function in lib/xmltok.c in libexpat in Expat 2.0.1, as used in the XML-Twig module for Perl, allows context-dependent attackers to cause a denial of service (application crash) via an XML document with malformed UTF-8 sequences that trigger a buffer over-read, related to the doProlog function in lib/xmlparse.c, a different vulnerability than CVE-2009-2625 and CVE-2009-3720.
Packages affected:
- python > 0-0 (version in image is 2.7.18-33.26.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-11543. Reason: This candidate is a duplicate of CVE-2017-11543. Notes: All CVE users should reference CVE-2017-11543 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- tcpdump > 0-0 (version in image is 4.9.2-14.20.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid WARN_ON timing related checksThe soft/batadv interface for a queued OGM can be changed during the timethe OGM was queued for transmission and when the OGM is actuallytransmitted by the worker.But WARN_ON must be used to denote kernel bugs and not to print simplewarnings. A warning can simply be printed using pr_warn.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: Fix shift-out-of-bound (UBSAN) with byte size cellsIf a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and wesubtract one from that making a large number that is then shifted more than thenumber of bits that fit into an unsigned long.UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20Fix it by making sure there are any bits to mask out.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.219.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fixmap: Fix VM debug warning on unmapUnmapping a fixmap entry is done by calling __set_fixmap()with FIXMAP_PAGE_CLEAR as flags.Today, powerpc __set_fixmap() calls map_kernel_page().map_kernel_page() is not happy when called a second timefor the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 NIP [c0017cd4] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Call Trace: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable) [e1011e30] [c0165fec] __set_fixmap+0x30/0x44 [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030Implement unmap_kernel_page() which clears an existing pte.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix warning message due to adisc being flushedFix warning message due to adisc being flushed. Linux kernel triggered awarning message where a different error code type is not matching up withthe expected type. Add additional translation of one error code type toanother.WARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]CPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1..GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx]Call Trace:[c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable)[c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx][c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx][c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx][c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx][c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120[c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0[c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100[c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40[c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130[c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180[c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60[c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20][c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290[c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0[c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330[c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130[c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0[c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.255.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix UAF in cifs_demultiplex_thread()There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0The UAF is because: mount(pid: 921) | cifsd(pid: 923)-------------------------------|------------------------------- | cifs_demultiplex_threadSMB2_negotiate | cifs_send_recv | compound_send_recv | smb_send_rqst | wait_for_response | wait_event_state [1] | | standard_receive3 | cifs_handle_standard | handle_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] KILL the process [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_deleted [6] | callback1. After send request to server, wait the response until mid->mid_state != SUBMITTED;2. Receive response from server, and set it to mid;3. Set the mid state to RECEIVED;4. Kill the process, the mid state already RECEIVED, get 0;5. Handle and release the negotiate response;6. UAF.It can be easily reproduce with add some delay in [3] - [6].Only sync call has the problem since async call's callback isexecuted in cifsd process.Add an extra state to mark the mid state to READY before wakeup thewaitter, then it can get the resp safely.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.250.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read()If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely onlpfc_read_object()'s routine to NULL check pdata.Currently, an early return error is thrown from lpfc_read_object() toprotect us from NULL ptr dereference, but the errno code is -ENODEV.Change the errno code to a more appropriate -ENOMEM.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Don't balance task to its current running CPUWe've run into the case that the balancer tries to balance a migrationdisabled task and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]---Further investigation shows that the warning is superfluous, the migrationdisabled task is just going to be migrated to its current running CPU.This is because that on load balance if the dst_cpu is not allowed by thetask, we'll re-select a new_dst_cpu as a candidate. If no task can bebalanced to dst_cpu we'll try to balance the task to the new_dst_cpuinstead. In this case when the migration disabled task is not on CPU itonly allows to run on its current CPU, load balance will select itscurrent CPU as new_dst_cpu and later triggers the warning above.The new_dst_cpu is chosen from the env->dst_grpmask. Currently itcontains CPUs in sched_group_span() and if we have overlapped groups it'spossible to run into this case. This patch makes env->dst_grpmask ofgroup_balance_mask() which exclude any CPUs from the busiest group andsolve the issue. For balancing in a domain with no overlapped groupsthe behaviour keeps same as before.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Remove unused nvme_ls_waitq wait queueSystem crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_upgets called for uninitialized wait queue sp->nvme_ls_waitq. qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0 qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removedpreviously in the commits tagged Fixed: below.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:start_kernel: Add __no_stack_protector function attributeBack during the discussion ofcommit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")we discussed the need for a function attribute to control the omissionof stack protectors on a per-function basis; at the time Clang hadsupport for no_stack_protector but GCC did not. This was fixed ingcc-11. Now that the function attribute is available, let's start usingit.Callers of boot_init_stack_canary need to use this function attributeunless they're compiled with -fno-stack-protector, otherwise the canarystored in the stack slot of the caller will differ upon the call toboot_init_stack_canary. This will lead to a call to __stack_chk_fail()then panic.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:qed: allow sleep in qed_mcp_trace_dump()By default, qed_mcp_cmd_and_union() delays 10us at a time in a loopthat can run 500K times, so calls to qed_mcp_nvm_rd_cmd()may block the current thread for over 5s.We observed thread scheduling delays over 700ms in production,with stacktraces pointing to this code as the culprit.qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().Add a "can sleep" parameter to qed_find_nvram_image() andqed_nvram_read() so they can sleep during qed_mcp_trace_dump().qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),called only by qed_mcp_trace_dump(), allow these functions to sleep.I can't tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,so keep b_can_sleep set to false when it calls these functions.An example stacktrace from a custom warning we added to the kernelshowing a thread that has not scheduled despite long needing resched:[ 2745.362925,17] ------------[ cut here ]------------[ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()[ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99[ 2745.362956,17] Modules linked in: ...[ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x[ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020[ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20[ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000[ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000[ 2745.363379,17] Call Trace:[ 2745.363382,17] [] dump_stack+0x8e/0xcf[ 2745.363393,17] [] warn_slowpath_common+0x82/0xc0[ 2745.363398,17] [] warn_slowpath_fmt+0x4c/0x50[ 2745.363404,17] [] ? rcu_irq_exit+0xae/0xc0[ 2745.363408,17] [] do_IRQ+0x15e/0x1a0[ 2745.363413,17] [] common_interrupt+0x89/0x89[ 2745.363416,17] [] ? delay_tsc+0x24/0x50[ 2745.363425,17] [] __udelay+0x34/0x40[ 2745.363457,17] [] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed][ 2745.363473,17] [] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed][ 2745.363490,17] [] qed_mcp_trace_dump+0x4a7/0x630 [qed][ 2745.363504,17] [] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed][ 2745.363520,17] [] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed][ 2745.363536,17] [] qed_dbg_feature_size+0x61/0xa0 [qed][ 2745.363551,17] [] qed_dbg_all_data_size+0x247/0x260 [qed][ 2745.363560,17] [] qede_get_regs_len+0x30/0x40 [qede][ 2745.363566,17] [] ethtool_get_drvinfo+0xe3/0x190[ 2745.363570,17] [] dev_ethtool+0x1362/0x2140[ 2745.363575,17] [] ? finish_task_switch+0x76/0x260[ 2745.363580,17] [] ? __schedule+0x3c6/0x9d0[ 2745.363585,17] [] ? hrtimer_start_range_ns+0x1d0/0x370[ 2745.363589,17] [] ? dev_get_by_name_rcu+0x6b/0x90[ 2745.363594,17] [] dev_ioctl+0xe8/0x710[ 2745.363599,17] [] sock_do_ioctl+0x48/0x60[ 2745.363603,17] [] sock_ioctl+0x1c7/0x280[ 2745.363608,17] [] ? seccomp_phase1+0x83/0x220[ 2745.363612,17] [] do_vfs_ioctl+0x2b3/0x4e0[ 2745.363616,17] [] SyS_ioctl+0x41/0x70[ 2745.363619,17] [] entry_SYSCALL_64_fastpath+0x1e/0x79[ 2745.363622,17] ---[ end trace f6954aa440266421 ]---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix handling of lrbp->cmdufshcd_queuecommand() may be called two times in a row for a SCSI commandbefore it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.See also scsi_send_eh_cmnd().This commit prevents that the following appears if a command times out:WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: check 'jh->b_transaction' before removing it from checkpointFollowing process will corrupt ext4 image:Step 1:jbd2_journal_commit_transaction __jbd2_journal_insert_checkpoint(jh, commit_transaction) // Put jh into trans1->t_checkpoint_list journal->j_checkpoint_transactions = commit_transaction // Put trans1 into journal->j_checkpoint_transactionsStep 2:do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2Step 3:drop_cache journal_shrink_one_cp_list jbd2_journal_try_remove_checkpoint if (!trylock_buffer(bh)) // lock bh, true if (buffer_dirty(bh)) // buffer is not dirty __jbd2_journal_remove_checkpoint(jh) // remove jh from trans1->t_checkpoint_listStep 4:jbd2_log_do_checkpoint trans1 = journal->j_checkpoint_transactions // jh is not in trans1->t_checkpoint_list jbd2_cleanup_journal_tail(journal) // trans1 is doneStep 5: Power cut, trans2 is not committed, jh is lost in next mounting.Fix it by checking 'jh->b_transaction' before remove it from checkpoint.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.275.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl logIt's trivial for user to trigger "verifier log line truncated" warning,as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are atleast two pieces of user-provided information that can be output throughthis buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.Verifier log buffer should be properly sized for typical verifier stateoutput. But it's sort-of expected that this buffer won't be long enoughin some circumstances. So let's drop the check. In any case code willwork correctly, at worst truncating a part of a single line output.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: remove BUG_ON()'s in add_new_free_space()At add_new_free_space() we have these BUG_ON()'s that are there to dealwith any failure to add free space to the in memory free space cache.Such failures are mostly -ENOMEM that should be very rare. However there'sno need to have these BUG_ON()'s, we can just return any error to thecaller and all callers and their upper call chain are already dealing witherrors.So just make add_new_free_space() return any errors, while removing theBUG_ON()'s, and returning the total amount of added free space to anoptional u64 pointer argument.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_---truncated---
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-public-cloud-release >= 12-0 (version in image is 12-7.3.1).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.244.1 (version in image is 4.12.14-122.179.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: curl's websocket code did not update the 32 bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask thatpersisted and was used throughout the entire connection.A predictable mask pattern allows for a malicious server to induce trafficbetween the two communicating parties that could be interpreted by an involvedproxy (configured or transparent) as genuine, real, HTTP traffic with contentand thereby poison its cache. That cached poisoned content could then beserved to all users of that proxy.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- curl < 8.0.1-11.108.1 (version in image is 8.0.1-11.74.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched 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 identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation 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 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Assign normalized_pix_clk when color depth = 14[WHY & HOW]A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because thedisplay_color_depth == COLOR_DEPTH_141414 is not handled. This isobserved in Radeon RX 6600 XT.It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.Also fixes the indentation in get_norm_pix_clk.(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.258.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix out-of-bound memcpy() during ethtool -wWhen retrieving the FW coredump using ethtool, it can sometimes causememory corruption:BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]ethtool_get_dump_data+0xdc/0x1a0__dev_ethtool+0xa1e/0x1af0dev_ethtool+0xa8/0x170dev_ioctl+0x1b5/0x580sock_do_ioctl+0xab/0xf0sock_ioctl+0x1ce/0x2e0__x64_sys_ioctl+0x87/0xc0do_syscall_64+0x5c/0xf0entry_SYSCALL_64_after_hwframe+0x78/0x80...This happens when copying the coredump segment list inbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.The info->dest_buf buffer is allocated based on the number of coredumpsegments returned by the FW. The segment list is then DMA'ed bythe FW and the length of the DMA is returned by FW. The driver thencopies this DMA'ed segment list to info->dest_buf.In some cases, this DMA length may exceed the info->dest_buf lengthand cause the above BUG condition. Fix it by capping the copylength to not exceed the length of info->dest_buf. The extraDMA data contains no useful information.This code path is shared for the HWRM_DBG_COREDUMP_LIST and theHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is differentfor these 2 FW commands. To simplify the logic, we need to movethe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVEup, so that the new check to cap the copy length will work for bothcommands.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.266.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sch_htb: make htb_qlen_notify() idempotenthtb_qlen_notify() always deactivates the HTB class and in fact couldtrigger a warning if it is already deactivated. Therefore, it is notidempotent and not friendly to its callers, like fq_codel_dequeue().Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers'life.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.261.1 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Annotate FDB data racesThe 'used' and 'updated' fields in the FDB entry structure can beaccessed concurrently by multiple threads, leading to reports such as[1]. Can be reproduced using [2].Suppress these reports by annotating these accesses usingREAD_ONCE() / WRITE_ONCE().[1]BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmitwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6fReported by Kernel Concurrency Sanitizer on:CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: cx231xx: set device_caps for 417The video_device for the MPEG encoder did not set device_caps.Add this, otherwise the video device can't be registered (you get aWARN_ON instead).Not seen before since currently 417 support is disabled, but I foundthis while experimenting with it.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().As syzbot reported [0], mpls_route_input_rcu() can be calledfrom mpls_getroute(), where is under RTNL.net->mpls.platform_label is only updated under RTNL.Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() tosilence the splat.[0]:WARNING: suspicious RCU usage6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ----------------------------net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961stack backtrace:CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0a2818e969Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix the setting of capabilities when automounting a new filesystemCapabilities cannot be inherited when we cross into a new filesystem.They need to be reset to the minimal defaults, and then probed foragain.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Remove WARN_ON for device endpoint command timeoutsThis commit addresses a rarely observed endpoint command timeoutwhich causes kernel panic due to warn when 'panic_on_warn' is enabledand unnecessary call trace prints when 'panic_on_warn' is disabled.It is seen during fast software-controlled connect/disconnect testcases.The following is one such endpoint command timeout that we observed:1. Connect =======->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd2. Disconnect ==========->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmdIn the issue scenario, in Exynos platforms, we observed that controltransfers for the previous connect have not yet been completed and endtransfer command sent as a part of the disconnect sequence andprocessing of USB_ENDPOINT_HALT feature request from the host timeout.This maybe an expected scenario since the controller is processing EPcommands sent as a part of the previous connect. It maybe better toremove WARN_ON in all places where device endpoint commands are sent toavoid unnecessary kernel panic due to warn.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
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:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default > 0-0 (version in image is 4.12.14-122.179.1).
-
Description: Libgcrypt before 1.5.4, as used in GnuPG and other products, does not properly perform ciphertext normalization and ciphertext randomization, which makes it easier for physically proximate attackers to conduct key-extraction attacks by leveraging the ability to collect voltage data from exposed metal, a different vector than CVE-2013-4576.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- libgcrypt20 > 0-0 (version in image is 1.6.1-16.83.1).
-
Description: The resolve_redirects function in sessions.py in requests 2.1.0 through 2.5.3 allows remote attackers to conduct session fixation attacks via a cookie without a host value in a redirect.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- python-requests > 0-0 (version in image is 2.24.0-8.14.1).
-
Description: A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- binutils > 0-0 (version in image is 2.41-9.53.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- kernel-default < 4.12.14-122.216.1 (version in image is 4.12.14-122.179.1).
- sles-release == 12.5 (version in image is 12.5-1.171).
-
Description: Unknown.
Packages affected:
- sles-release == 12.5 (version in image is 12.5-1.171).
- kernel-default < 4.12.14-122.225.1 (version in image is 4.12.14-122.179.1).