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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s: Fix VAS mm use after freeThe refcount on mm is dropped before the coprocessor is detached.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix missed ses refcountingUse new cifs_smb_ses_inc_refcount() helper to get an active referenceof @ses and @ses->dfs_root_ses (if set). This will prevent@ses->dfs_root_ses of being put in the next call to cifs_put_smb_ses()and thus potentially causing an use-after-free bug.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: cancel mesh send timer when hdev removedmesh_send_done timer is not canceled when hdev is removed, which causescrash if the timer triggers after hdev is gone.Cancel the timer when MGMT removes the hdev, like other MGMT timers.Should fix the BUG: sporadically seen by BlueZ test bot(in "Mesh - Send cancel - 1" test).Log:------BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0...Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240------
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
tar > 0-0 (version in image is 1.35-slfo.1.1_1.2).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()nft_map_catchall_activate() has an inverted element activity checkcompared to its non-catchall counterpart nft_mapelem_activate() andcompared to what is logically required.nft_map_catchall_activate() is called from the abort path to re-activatecatchall map elements that were deactivated during a failed transaction.It should skip elements that are already active (they don't needre-activation) and process elements that are inactive (they need to berestored). Instead, the current code does the opposite: it skips inactiveelements and processes active ones.Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */The consequence is that when a DELSET operation is aborted,nft_setelem_data_activate() is never called for the catchall element.For NFT_GOTO verdict elements, this means nft_data_hold() is nevercalled to restore the chain->use reference count. Each abort cyclepermanently decrements chain->use. Once chain->use reaches zero,DELCHAIN succeeds and frees the chain while catchall verdict elementsstill reference it, resulting in a use-after-free.This is exploitable for local privilege escalation from an unprivilegeduser via user namespaces + nftables on distributions that enableCONFIG_USER_NS and CONFIG_NF_TABLES.Fix by removing the negation so the check matches nft_mapelem_activate():skip active elements, process inactive ones.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix error recovery in macvlan_common_newlink()valis provided a nice repro to crash the kernel:ip link add p1 type veth peer p2ip link set address 00:00:00:00:00:20 dev p1ip link set up dev p1ip link set up dev p2ip link add mv0 link p2 type macvlan mode sourceip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20ping -c1 -I p1 1.2.3.4He also gave a very detailed analysis:The issue is triggered when a new macvlan link is created withMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (orMACVLAN_MACADDR_SET) parameter, lower device already has a macvlanport and register_netdevice() called from macvlan_common_newlink()fails (e.g. because of the invalid link name).In this case macvlan_hash_add_source is called frommacvlan_change_sources() / macvlan_common_newlink():This adds a reference to vlan to the port's vlan_source_hash usingmacvlan_source_entry.vlan is a pointer to the priv data of the link that is being created.When register_netdevice() fails, the error is returned frommacvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; }and free_netdev() is called, causing a kvfree() on the structnet_device that is still referenced in the source entry attached tothe lower device's macvlan port.Now all packets sent on the macvlan port with a matching source macaddress will trigger a use-after-free in macvlan_forward_source().With all that, my fix is to make sure we call macvlan_flush_sources()regardless of @create value whenever "goto destroy_macvlan_port;"path is taken.Many thanks to valis for following up on this issue.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Issue summary: PBMAC1 parameters in PKCS#12 files are missing validationwhich can trigger a stack-based buffer overflow, invalid pointer or NULLpointer dereference during MAC verification.Impact summary: The stack buffer overflow or NULL pointer dereference maycause a crash leading to Denial of Service for an application that parsesuntrusted PKCS#12 files. The buffer overflow may also potentially enablecode execution depending on platform mitigations.When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2salt and keylength parameters from the file are used without validation.If the value of keylength exceeds the size of the fixed stack buffer usedfor the derived key (64 bytes), the key derivation will overflow the buffer.The overflow length is attacker-controlled. Also, if the salt parameter isnot an OCTET STRING type this can lead to invalid or NULL pointerdereference.Exploiting this issue requires a user or application to processa maliciously crafted PKCS#12 file. It is uncommon to accept untrustedPKCS#12 files in applications as they are usually used to store privatekeys which are trusted by definition. For this reason the issue was assessedas Moderate severity.The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, asPKCS#12 processing is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they donot support PBMAC1 in PKCS#12.
Packages affected:
libopenssl3 > 0-0 (version in image is 3.1.4-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
containerd > 0-0 (version in image is 1.7.29-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: duplicate handshake cancellations leak socketWhen a handshake request is cancelled it is removed from thehandshake_net->hn_requests list, but it is still present in thehandshake_rhashtbl until it is destroyed.If a second cancellation request arrives for the same handshake request,then remove_pending() will return false... and assumingHANDSHAKE_F_REQ_COMPLETED isn't set in req->hr_flags, we'll continueprocessing through the out_true label, where we put another reference onthe sock and a refcount underflow occurs.This can happen for example if a handshake times out - particularly ifthe SUNRPC client sends the AUTH_TLS probe to the server but doesn'tfollow it up with the ClientHello due to a problem with tlshd. When thetimeout is hit on the server, the server will send a FIN, which triggersa cancellation request via xs_reset_transport(). When the timeout ishit on the client, another cancellation request happens viaxs_tls_handshake_sync().Add a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) in the pending cancelpath so duplicate cancels can be detected.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error pathsThe problem occurs when a signed request fails smb2 signature verificationcheck. In __process_request(), if check_sign_req() returns an error,set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resettingnext_smb2_rcv_hdr_off to zero, the pointer to the next command in the chainis lost. Consequently, is_chained_smb2_message() continues to point tothe same request header instead of advancing. If the header's NextCommandfield is non-zero, the function returns true, causing __handle_ksmbd_work()to repeatedly process the same failed request in an infinite loop.This results in the kernel log being flooded with "bad smb2 signature"messages and high CPU usage.This patch fixes the issue by changing the return value fromSERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures thatthe processing loop terminates immediately rather than attempting tocontinue from an invalidated offset.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: time provides date and time handling in Rust. From 0.3.6 to before 0.3.47, when user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario. A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.
Packages affected:
aardvark-dns > 0-0 (version in image is 1.12.2-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A flaw was found in Podman. In a Containerfile or Podman, data written to RUN --mount=type=bind mounts during the podman build is not discarded. This issue can lead to files created within the container appearing in the temporary build context directory on the host, leaving the created files accessible.
Packages affected:
podman > 0-0 (version in image is 5.4.2-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds writes in handle_auth_session_key()The len field originates from untrusted network packets. Boundarychecks have been added to prevent potential out-of-bounds writes whendecrypting the connection secret or processing service tickets.[ idryomov: changelog ]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: aloop: Fix racy access at PCM triggerThe PCM trigger callback of aloop driver tries to check the PCM stateand stop the stream of the tied substream in the corresponding cable.Since both check and stop operations are performed outside the cablelock, this may result in UAF when a program attempts to triggerfrequently while opening/closing the tied stream, as spotted byfuzzers.For addressing the UAF, this patch changes two things:- It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses.- In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:FS: JFS: Check for read-only mounted filesystem in txBegin This patch adds a check for read-only mounted filesystem in txBegin before starting a transaction potentially saving from NULL pointer deref.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()KASAN reports that there's a use-after-free inhci_remove_adv_monitor(). Trawling through the disassembly, you cansee that the complaint is from the access in bt_dev_dbg() under theHCI_ADV_MONITOR_EXT_MSFT case. The problem case happens becausemsft_remove_monitor() can end up freeing the monitorstructure. Specifically: hci_remove_adv_monitor() -> msft_remove_monitor() -> msft_remove_monitor_sync() -> msft_le_cancel_monitor_advertisement_cb() -> hci_free_adv_monitor()Let's fix the problem by just stashing the relevant data when it'sstill valid.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Prevent use-after-free during requeue-PIsyzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL);In this scenario futex_wait_requeue_pi() is able to leave without usingfutex_q::lock_ptr for synchronization.This can be prevented by reading futex_q::task before updating thefutex_q::requeue_state. A reference on the task_struct is not neededbecause requeue_pi_wake_futex() is invoked with a spinlock_t held whichimplies a RCU read section.Even if T1 terminates immediately after, the task_struct will remain validduring T2's wake_up_state(). A READ_ONCE on futex_q::task beforefutex_requeue_pi_complete() is enough because it ensures that the variableis read before the state is updated.Read futex_q::task before updating the requeue state, use it for thefollowing wakeup.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race condition in mptcp_schedule_work()syzbot reported use-after-free in mptcp_schedule_work() [1]Issue here is that mptcp_schedule_work() schedules a work,then gets a refcount on sk->sk_refcnt if the work was scheduled.This refcount will be released by mptcp_worker().[A] if (schedule_work(...)) {[B] sock_hold(sk); return true; }Problem is that mptcp_worker() can run immediately and complete before [B]We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk);[1]refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix use-after-free due to MST port state bypasssyzbot reported[1] a use-after-free when deleting an expired fdb. It isdue to a race condition between learning still happening and a port beingdeleted, after all its fdbs have been flushed. The port's state has beentoggled to disabled so no learning should happen at that time, but if wehave MST enabled, it will bypass the port's state, that together with VLANfiltering disabled can lead to fdb learning at a time when it shouldn'thappen while the port is being deleted. VLAN filtering must be disabledbecause we flush the port VLANs when it's being deleted which will stoplearning. This fix adds a check for the port's vlan group which isinitialized to NULL when the port is getting deleted, that avoids the portstate bypass. When MST is enabled there would be a minimal new overheadin the fast-path because the port's vlan group pointer is cache-hot.[1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix race in syncpt alloc/freeFix race condition between host1x_syncpt_alloc()and host1x_syncpt_put() by using kref_put_mutex()instead of kref_put() + manual mutex locking.This ensures no thread can acquire thesyncpt_mutex after the refcount drops to zerobut before syncpt_release acquires it.This prevents races where syncpoints couldbe allocated while still being cleaned upfrom a previous release.Remove explicit mutex locking in syncpt_releaseas kref_put_mutex() handles this atomically.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driverAfter unbinding the driver, another kthread `cros_ec_console_log_work`is still accessing the device, resulting an UAF and crash.The driver doesn't unregister the EC device in .remove() which shouldshutdown sub-devices synchronously. Fix it.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Always remove class from active list before deleting in ets_qdisc_changezdi-disclosures@trendmicro.com says:The vulnerability is a race condition between `ets_qdisc_dequeue` and`ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.Attacker requires the capability to create new user and network namespacein order to trigger the bug.See my additional commentary at the end of the analysis.Analysis:static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack){... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc); } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0;}Comment:This happens because some of the classes have their qdiscs assigned toNULL, but remain in the active list. This commit fixes this issue by alwaysremoving the class from the active list before deleting and freeing itsassociated qdiscReproducer Steps(trimmed version of what was sent by zdi-disclosures@trendmicro.com)```DEV="${DEV:-lo}"ROOT_HANDLE="${ROOT_HANDLE:-1:}"BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2PING_BYTES="${PING_BYTES:-48}"PING_COUNT="${PING_COUNT:-200000}"PING_DST="${PING_DST:-127.0.0.1}"SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null}trap cleanup EXITip link set "$DEV" uptc qdisc del dev "$DEV" root 2>/dev/null || truetc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2tc -s qdisc ls dev $DEVping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 &tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc -s qdisc ls dev $DEVtc qdisc del dev "$DEV" parent ---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu: disable SVA when CONFIG_X86 is setPatch series "Fix stale IOTLB entries for kernel address space", v7.This proposes a fix for a security vulnerability related to IOMMU SharedVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernelpage table entries. When a kernel page table page is freed andreallocated for another purpose, the IOMMU might still hold stale,incorrect entries. This can be exploited to cause a use-after-free orwrite-after-free condition, potentially leading to privilege escalation ordata corruption.This solution introduces a deferred freeing mechanism for kernel pagetable pages, which provides a safe window to notify the IOMMU toinvalidate its caches before the page is reused.This patch (of 8):In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardwareshares and walks the CPU's page tables. The x86 architecture maps thekernel's virtual address space into the upper portion of every process'spage table. Consequently, in an SVA context, the IOMMU hardware can walkand cache kernel page table entries.The Linux kernel currently lacks a notification mechanism for kernel pagetable changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual addressmappings. This can cause the IOMMU's internal caches to retain staleentries for kernel VA.Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise whenkernel page table pages are freed and later reallocated. The IOMMU couldmisinterpret the new data as valid page table entries. The IOMMU mightthen walk into attacker-controlled memory, leading to arbitrary physicalmemory DMA access or privilege escalation. This is also aWrite-After-Free issue, as the IOMMU will potentially continue to writeAccessed and Dirty bits to the freed memory while attempting to walk thestale page tables.Currently, SVA contexts are unprivileged and cannot access kernelmappings. However, the IOMMU will still walk kernel-only page tables allthe way down to the leaf entries, where it realizes the mapping is for thekernel and errors out. This means the IOMMU still caches theseintermediate page table entries, making the described vulnerability a realconcern.Disable SVA on x86 architecture until the IOMMU can receive notificationto flush the paging cache before freeing the CPU kernel page table pages.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: isp1301: fix non-OF device reference imbalanceA recent change fixing a device reference leak in a UDC driverintroduced a potential use-after-free in the non-OF case as theisp1301_get_client() helper only increases the reference count for thereturned I2C device in the OF case.Increment the reference count also for non-OF so that the caller candecrement it unconditionally.Note that this is inherently racy just as using the returned I2C deviceis since nothing is preventing the PHY driver from being unbound whilein use.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: do not free existing class in qfq_change_class()Fixes qfq_change_class() error case.cl->qdisc and cl should only be freed if a new class and qdiscwere allocated, or we risk various UAF.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix possible UAF in macvlan_forward_source()Add RCU protection on (struct macvlan_source_entry)->vlan.Whenever macvlan_hash_del_source() is called, we must clearentry->vlan pointer before RCU grace period starts.This allows macvlan_forward_source() to skip overentries queued for freeing.Note that macvlan_dev are already RCU protected, as theyare embedded in a standard netdev (netdev_priv(ndev)).https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()in an interesting way [1]Crash happens in list_del_init()/INIT_LIST_HEAD() while writinglist->prev, while the prior write on list->next went well.static inline void INIT_LIST_HEAD(struct list_head *list){ WRITE_ONCE(list->next, list); // This went well WRITE_ONCE(list->prev, list); // Crash, @list has been freed.}Issue here is that rt6_uncached_list_del() did not attempt to lockul->lock, as list_empty(&rt->dst.rt_uncached) returnedtrue because the WRITE_ONCE(list->next, list) happened on the other CPU.We might use list_del_init_careful() and list_empty_careful(),or make sure rt6_uncached_list_del() always grabs the spinlockwhenever rt->dst.rt_uncached_list has been set.A similar fix is neeed for IPv4.[1] BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline] BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline] BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: netns cleanup_netCall Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 INIT_LIST_HEAD include/linux/list.h:46 [inline] list_del_init include/linux/list.h:296 [inline] rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853 addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] netif_close_many+0x29c/0x410 net/core/dev.c:1785 unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248 cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 803: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4953 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270 dst_alloc+0x105/0x170 net/core/dst.c:89 ip6_dst_alloc net/ipv6/route.c:342 [inline] icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333 mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recvmsg() unconditional requeueIf rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call atthe front of the recvmsg queue already has its mutex locked, it requeuesthe call - whether or not the call is already queued. The call may be onthe queue because MSG_PEEK was also passed and so the call was not dequeuedor because the I/O thread requeued it.The unconditional requeue may then corrupt the recvmsg queue, leading tothings like UAFs or refcount underruns.Fix this by only requeuing the call if it isn't already on the queue - andmoving it to the front if it is already queued. If we don't queue it, wehave to put the ref we obtained by dequeuing it.Also, MSG_PEEK doesn't dequeue the call so shouldn't callrxrpc_notify_socket() for the call if we didn't use up all the data on thequeue, so fix that also.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Enforce that teql can only be used as root qdiscDesign intent of teql is that it is only supposed to be used as root qdisc.We need to check for that constraint.Although not important, I will describe the scenario that unearthed thisissue for the curious.GangMin Kim managed to concot a scenario as follows:ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s ── class 1:2 (weight=1, lmax=1514) teqlGangMin sends a packet which is enqueued to 1:1 (netem).Any invocation of dequeue by QFQ from this class will not return a packetuntil after 6.4s. In the meantime, a second packet is sent and it lands on1:2. teql's enqueue will return success and this will activate class 1:2.Main issue is that teql only updates the parent visible qlen (sch->q.qlen)at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql'speek always returns NULL), dequeue will never be called and thus the qlenwill remain as 0. With that in mind, when GangMin updates 1:2's lmax value,the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc'sqlen was not incremented, qfq fails to deactivate the class, but stillfrees its pointers from the aggregate. So when the first packet isrescheduled after 6.4 seconds (netem's delay), a dangling pointer isaccessed causing GangMin's causing a UAF.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_u32: use skb_header_pointer_careful()skb_header_pointer() does not fully validate negative @offset values.Use skb_header_pointer_careful() instead.GangMin Kim provided a report and a repro fooling u32_classify():BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0net/sched/cls_u32.c:221
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/freeExynos Virtual Display driver performs memory alloc/free operationswithout lock protection, which easily causes concurrency problem.For example, use-after-free can occur in race scenario like this:``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ...```To prevent these vulns, at least in vidi_context, member variables relatedto memory alloc/free should be protected with ctx->lock.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Clear the driver reference in usb-phy devFor the dual-role port, it will assign the phy dev to usb-phy dev anduse the port dev driver as the dev driver of usb-phy.When we try to destroy the port dev, it will destroy its dev driveras well. But we did not remove the reference from usb-phy dev. Thismight cause the use-after-free issue in KASAN.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_router: Fix neighbour use-after-freeWe sometimes observe use-after-free when dereferencing a neighbour [1].The problem seems to be that the driver stores a pointer to theneighbour, but without holding a reference on it. A reference is onlytaken when the neighbour is used by a nexthop.Fix by simplifying the reference counting scheme. Always take areference when storing a neighbour pointer in a neighbour entry. Avoidtaking a referencing when the neighbour is used by a nexthop as theneighbour entry associated with the nexthop already holds a reference.Tested by running the test that uncovered the problem over 300 times.Without this patch the problem was reproduced after a handful ofiterations.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310Read of size 8 at addr ffff88817f8e3420 by task ip/3929CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[...]Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: provide locking for v4_end_graceWriting to v4_end_grace can race with server shutdown and result inmemory being accessed after it was freed - reclaim_str_hashtbl inparticularly.We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that isheld while client_tracking_op->init() is called and that can wait foran upcall to nfsdcltrack which can write to v4_end_grace, resulting in adeadlock.nfsd4_end_grace() is also called by the landromat work queue and thisdoesn't require locking as server shutdown will stop the work and waitfor it before freeing anything that nfsd4_end_grace() might access.However, we must be sure that writing to v4_end_grace doesn't restartthe work item after shutdown has already waited for it. For this weadd a new flag protected with nn->client_lock. It is set only while itis safe to make client tracking calls, and v4_end_grace only scheduleswork while the flag is set with the spinlock held.So this patch adds a nfsd_net field "client_tracking_active" which isset as described. Another field "grace_end_forced", is set whenv4_end_grace is written. After this is set, and providingclient_tracking_active is set, the laundromat is scheduled.This "grace_end_forced" field bypasses other checks for whether thegrace period has finished.This resolves a race which can result in use-after-free.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()Check the write offset end bounds before using it as the offset into thepivot array. This avoids a possible out-of-bounds access on the pivotarray if the write extends to the last slot in the node, in which case thenode maximum should be used as the end pivot.akpm: this doesn't affect any current callers, but new users of mapletreemay encounter this problem if backported into earlier kernels, so let'sfix it in -stable kernels in case of this.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Array index may go out of boundKlocwork reports array 'vha->host_str' of size 16 may use index value(s)16..19. Use snprintf() instead of sprintf().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: Fix possible overflow condition in iomap_write_delalloc_scanfolio_next_index() returns an unsigned long value which left shiftedby PAGE_SHIFT could possibly cause an overflow on 32-bit system. Insteaduse folio_pos(folio) + folio_size(folio), which does this correctly.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Disable preemption in bpf_perf_event_outputThe nesting protection in bpf_perf_event_output relies on disabledpreemption, which is guaranteed for kprobes and tracepoints.However bpf_perf_event_output can be also called from uprobes contextthrough bpf_prog_run_array_sleepable function which disables migration,but keeps preemption enabled.This can cause task to be preempted by another one inside the nestingprotection and lead eventually to two tasks using same perf_sample_databuffer and cause crashes like: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffffff82be3eea ... Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x176/0x4d0 ? exc_page_fault+0x132/0x230 ? asm_exc_page_fault+0x22/0x30 ? perf_output_sample+0x12b/0x910 ? perf_event_output+0xd0/0x1d0 ? bpf_perf_event_output+0x162/0x1d0 ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87 ? __uprobe_perf_func+0x12b/0x540 ? uprobe_dispatcher+0x2c4/0x430 ? uprobe_notify_resume+0x2da/0xce0 ? atomic_notifier_call_chain+0x7b/0x110 ? exit_to_user_mode_prepare+0x13e/0x290 ? irqentry_exit_to_user_mode+0x5/0x30 ? asm_exc_int3+0x35/0x40Fixing this by disabling preemption in bpf_perf_event_output.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: potential integer overflow in usbg_make_tpg()The variable tpgt in usbg_make_tpg() is defined as unsigned long and isassigned to tpgt->tport_tpgt, which is defined as u16. This may cause aninteger overflow when tpgt is greater than USHRT_MAX (65535). Ihaven't tried to trigger it myself, but it is possible to trigger itby calling usbg_make_tpg() with a large value for tpgt.I modified the type of tpgt to match tpgt->tport_tpgt and adjusted therelevant code accordingly.This patch is similar to commit 59c816c1f24d ("vhost/scsi: potentialmemory corruption").
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()If irq_domain_translate_twocell() sets "hwirq" to >= MCHP_EIC_NIRQ (2) thenit results in an out of bounds access.The code checks for invalid values, but doesn't set the error code. Return-EINVAL in that case, instead of returning success.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Input: ti_am335x_tsc - fix off-by-one error in wire_order validationThe current validation 'wire_order[i] > ARRAY_SIZE(config_pins)' allowswire_order[i] to equal ARRAY_SIZE(config_pins), which causes out-of-boundsaccess when used as index in 'config_pins[wire_order[i]]'.Since config_pins has 4 elements (indices 0-3), the valid range forwire_order should be 0-3. Fix the off-by-one error by using >= insteadof > in the validation check.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Coalesce only linear skbvsock/virtio common tries to coalesce buffers in rx queue: if a linear skb(with a spare tail room) is followed by a small skb (length limited byGOOD_COPY_LEN = 128), an attempt is made to join them.Since the introduction of MSG_ZEROCOPY support, assumption that a small skbwill always be linear is incorrect. In the zerocopy case, data is lost andthe linear skb is appended with uninitialized kernel memory.Of all 3 supported virtio-based transports, only loopback-transport isaffected. G2H virtio-transport rx queue operates on explicitly linear skbs;see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2Gvhost-transport may allocate non-linear skbs, but only for sizes that arenot considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER invirtio_vsock_alloc_skb().Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) > 0guarantees last_skb is linear.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Move representor neigh cleanup to profile cleanup_txFor IP tunnel encapsulation in ECMP (Equal-Cost Multipath) mode, asthe flow is duplicated to the peer eswitch, the related neighbourinformation on the peer uplink representor is created as well.In the cited commit, eswitch devcom unpair is moved to uplink unloadAPI, specifically the profile->cleanup_tx. If there is a encap ruleoffloaded in ECMP mode, when one eswitch does unpair (because ofunloading the driver, for instance), and the peer rule from the peereswitch is going to be deleted, the use-after-free error is triggeredwhile accessing neigh info, as it is already cleaned up in uplink'sprofile->disable, which is before its profile->cleanup_tx.To fix this issue, move the neigh cleanup to profile's cleanup_txcallback, and after mlx5e_cleanup_uplink_rep_tx is called. The neighinit is moved to init_tx for symmeter.[ 2453.376299] BUG: KASAN: slab-use-after-free in mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.379125] Read of size 4 at addr ffff888127af9008 by task modprobe/2496[ 2453.381542] CPU: 7 PID: 2496 Comm: modprobe Tainted: G B 6.4.0-rc7+ #15[ 2453.383386] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 2453.384335] Call Trace:[ 2453.384625] [ 2453.384891] dump_stack_lvl+0x33/0x50[ 2453.385285] print_report+0xc2/0x610[ 2453.385667] ? __virt_addr_valid+0xb1/0x130[ 2453.386091] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.386757] kasan_report+0xae/0xe0[ 2453.387123] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.387798] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.388465] mlx5e_rep_encap_entry_detach+0xa6/0xe0 [mlx5_core][ 2453.389111] mlx5e_encap_dealloc+0xa7/0x100 [mlx5_core][ 2453.389706] mlx5e_tc_tun_encap_dests_unset+0x61/0xb0 [mlx5_core][ 2453.390361] mlx5_free_flow_attr_actions+0x11e/0x340 [mlx5_core][ 2453.391015] ? complete_all+0x43/0xd0[ 2453.391398] ? free_flow_post_acts+0x38/0x120 [mlx5_core][ 2453.392004] mlx5e_tc_del_fdb_flow+0x4ae/0x690 [mlx5_core][ 2453.392618] mlx5e_tc_del_fdb_peers_flow+0x308/0x370 [mlx5_core][ 2453.393276] mlx5e_tc_clean_fdb_peer_flows+0xf5/0x140 [mlx5_core][ 2453.393925] mlx5_esw_offloads_unpair+0x86/0x540 [mlx5_core][ 2453.394546] ? mlx5_esw_offloads_set_ns_peer.isra.0+0x180/0x180 [mlx5_core][ 2453.395268] ? down_write+0xaa/0x100[ 2453.395652] mlx5_esw_offloads_devcom_event+0x203/0x530 [mlx5_core][ 2453.396317] mlx5_devcom_send_event+0xbb/0x190 [mlx5_core][ 2453.396917] mlx5_esw_offloads_devcom_cleanup+0xb0/0xd0 [mlx5_core][ 2453.397582] mlx5e_tc_esw_cleanup+0x42/0x120 [mlx5_core][ 2453.398182] mlx5e_rep_tc_cleanup+0x15/0x30 [mlx5_core][ 2453.398768] mlx5e_cleanup_rep_tx+0x6c/0x80 [mlx5_core][ 2453.399367] mlx5e_detach_netdev+0xee/0x120 [mlx5_core][ 2453.399957] mlx5e_netdev_change_profile+0x84/0x170 [mlx5_core][ 2453.400598] mlx5e_vport_rep_unload+0xe0/0xf0 [mlx5_core][ 2453.403781] mlx5_eswitch_unregister_vport_reps+0x15e/0x190 [mlx5_core][ 2453.404479] ? mlx5_eswitch_register_vport_reps+0x200/0x200 [mlx5_core][ 2453.405170] ? up_write+0x39/0x60[ 2453.405529] ? kernfs_remove_by_name_ns+0xb7/0xe0[ 2453.405985] auxiliary_bus_remove+0x2e/0x40[ 2453.406405] device_release_driver_internal+0x243/0x2d0[ 2453.406900] ? kobject_put+0x42/0x2d0[ 2453.407284] bus_remove_device+0x128/0x1d0[ 2453.407687] device_del+0x240/0x550[ 2453.408053] ? waiting_for_supplier_show+0xe0/0xe0[ 2453.408511] ? kobject_put+0xfa/0x2d0[ 2453.408889] ? __kmem_cache_free+0x14d/0x280[ 2453.409310] mlx5_rescan_drivers_locked.part.0+0xcd/0x2b0 [mlx5_core][ 2453.409973] mlx5_unregister_device+0x40/0x50 [mlx5_core][ 2453.410561] mlx5_uninit_one+0x3d/0x110 [mlx5_core][ 2453.411111] remove_one+0x89/0x130 [mlx5_core][ 24---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set page extent mapped after read_folio in relocate_one_pageOne of the CI runs triggered the following panic assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 sp : ffff800093213720 x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_set_dirty+0x38/0xa0 btrfs_page_set_dirty+0x58/0x88 relocate_one_page+0x204/0x5f0 relocate_file_extent_cluster+0x11c/0x180 relocate_data_extent+0xd0/0xf8 relocate_block_group+0x3d0/0x4e8 btrfs_relocate_block_group+0x2d8/0x490 btrfs_relocate_chunk+0x54/0x1a8 btrfs_balance+0x7f4/0x1150 btrfs_ioctl+0x10f0/0x20b8 __arm64_sys_ioctl+0x120/0x11d8 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x158 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)This is the same problem outlined in 17b17fcd6d44 ("btrfs:set_page_extent_mapped after read_folio in btrfs_cont_expand") , and thefix is the same. I originally looked for the same pattern elsewhere inour code, but mistakenly skipped over this code because I saw the pagecache readahead before we set_page_extent_mapped, not realizing thatthis was only in the !page case, that we can still end up with a!uptodate page and then do the btrfs_read_folio further down.The fix here is the same as the above mentioned patch, move theset_page_extent_mapped call to after the btrfs_read_folio() block tomake sure that we have the subpage blocksize stuff setup properly beforeusing the page.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g.
Packages affected:
podman > 0-0 (version in image is 5.4.2-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: 6lowpan: reset link-local header on ipv6 recv pathBluetooth 6lowpan.c netdev has header_ops, so it must set link-localheader for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAWAdd missing skb_reset_mac_header() for uncompressed ipv6 RX path.For the compressed one, it is done in lowpan_header_decompress().Log: (BlueZ 6lowpan-tester Client Recv Raw - Success)------kernel BUG at net/core/skbuff.c:212!Call Trace:...packet_rcv (net/packet/af_packet.c:2152)...__local_bh_enable_ip (kernel/softirq.c:407)netif_rx (net/core/dev.c:5648)chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359)------
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc()TID getting from ieee80211_get_tid() might be out of range of array sizeof sta_entry->tids[], so check TID is less than MAX_TID_COUNT. Othwerwise,UBSAN warn: UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtl_tid_data [9]'
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix string copying in parse_apply_sb_mount_options()strscpy_pad() can't be used to copy a non-NUL-term string into a NUL-termstring of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introducememtostr() and memtostr_pad()") provides additional information in thatregard. So if this happens, the following warning is observed:strnlen: detected buffer overflow: 65 byte read of buffer size 64WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032Modules linked in:CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032Call Trace: __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sized_strscpy include/linux/fortify-string.h:309 [inline] parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline] __ext4_fill_super fs/ext4/super.c:5261 [inline] ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706 get_tree_bdev_flags+0x387/0x620 fs/super.c:1636 vfs_get_tree+0x93/0x380 fs/super.c:1814 do_new_mount fs/namespace.c:3553 [inline] path_mount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __do_sys_mount fs/namespace.c:4103 [inline] __se_sys_mount fs/namespace.c:4080 [inline] __x64_sys_mount+0x280/0x300 fs/namespace.c:4080 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7eSince userspace is expected to provide s_mount_opts field to be at most 63characters long with the ending byte being NUL-term, use a 64-byte bufferwhich matches the size of s_mount_opts, so that strscpy_pad() does its jobproperly. Return with error if the user still managed to provide anon-NUL-term string here.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds reads in handle_auth_done()Perform an explicit bounds check on payload_len to avoid a possibleout-of-bounds access in the callout.[ idryomov: changelog ]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace overzealous BUG_ON in osdmap_apply_incremental()If the osdmap is (maliciously) corrupted such that the incrementalosdmap epoch is different from what is expected, there is no need toBUG. Instead, just declare the incremental osdmap to be invalid.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: return the handler error from mon_handle_auth_done()Currently any error from ceph_auth_handle_reply_done() is propagatedvia finish_auth() but isn't returned from mon_handle_auth_done(). Thisresults in higher layers learning that (despite the monitor consideringus to be successfully authenticated) something went wrong in theauthentication phase and reacting accordingly, but msgr2 still tryingto proceed with establishing the session in the background. In thecase of secure mode this can trigger a WARN in setup_crypto() and laterlead to a NULL pointer dereference inside of prepare_auth_signature().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: cap TX credit to local buffer sizeThe virtio transports derives its TX credit directly from peer_buf_alloc,which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.On the host side this means that the amount of data we are willing toqueue for a connection is scaled by a guest-chosen buffer size, ratherthan the host's own vsock configuration. A malicious guest can advertisea large buffer and read slowly, causing the host to allocate acorrespondingly large amount of sk_buff memory.The same thing would happen in the guest with a malicious host, sincevirtio transports share the same code base.Introduce a small helper, virtio_transport_tx_buf_size(), thatreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consumepeer_buf_alloc.This ensures the effective TX window is bounded by both the peer'sadvertised buffer and our own buf_alloc (already clamped tobuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peercannot force the other to queue more data than allowed by its ownvsock settings.On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with32 guest vsock connections advertising 2 GiB each and reading slowlydrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system onlyrecovered after killing the QEMU process. That said, if QEMU memory islimited with cgroups, the maximum memory used will be limited.With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiBOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guestremains responsive.Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.This change is limited to virtio_transport_common.c and thus affectsvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the"remote window intersected with local policy" behaviour that VMCI andHyper-V already effectively have.[Stefano: small adjustments after changing the previous patch][Stefano: tweak the commit message]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix UAF in xchk_btree_check_block_ownerWe cannot dereference bs->cur when trying to determine if bs->curaliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.Fix this by sampling before type before any freeing could happen.The correct temporal ordering was broken when we removed xfs_btnum_t.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Set fb_display[i]->mode to NULL when the mode is releasedRecently, we discovered the following issue through syzkaller:BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0Read of size 4 at addr ff11000001b3c69c by task syz.xxx...Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eBased on experimentation and analysis, during framebuffer unregistration,only the memory of fb_info->modelist is freed, without setting thecorresponding fb_display[i]->mode to NULL for the freed modes. This leadsto UAF issues during subsequent accesses. Here's an example of reproductionsteps:1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1;2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);3. Switch console from fb to VGA (to allow normal rmmod of the ko);4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[];5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.Add a check in do_unregister_framebuffer(): if the mode to be freed existsin fb_display[], set the corresponding mode pointer to NULL.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: avoid scheduling association deletion twiceWhen forcefully shutting down a port via the configfs interface,nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() andthen nvmet_disable_port(). Both functions will eventually schedule allremaining associations for deletion.The current implementation checks whether an association is about to beremoved, but only after the work item has already been scheduled. As aresult, it is possible for the first scheduled work item to free allresources, and then for the same work item to be scheduled again fordeletion.Because the association list is an RCU list, it is not possible to takea lock and remove the list entry directly, so it cannot be looked upagain. Instead, a flag (terminating) must be used to determine whetherthe association is already in the process of being deleted.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_mr: Fix use-after-free when updating multicast route statsCited commit added a dedicated mutex (instead of RTNL) to protect themulticast route list, so that it will not change while the driverperiodically traverses it in order to update the kernel about multicastroute stats that were queried from the device.One instance of list entry deletion (during route replace) was missedand it can result in a use-after-free [1].Fix by acquiring the mutex before deleting the entry from the list andreleasing it afterwards.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]Call Trace: dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: stm32: sai: fix OF node leak on probeThe reference taken to the sync provider OF node when probing theplatform device is currently only dropped if the set_sync() callbackfails during DAI probe.Make sure to drop the reference on platform probe failures (e.g. probedeferral) and on driver unbind.This also avoids a potential use-after-free in case the DAI is everreprobed without first rebinding the platform driver.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: fix enumeration completionThe soundwire subsystem uses two completion structures that allowdrivers to wait for soundwire device to become enumerated on the bus andinitialised by their drivers, respectively.The code implementing the signalling is currently broken as it does notsignal all current and future waiters and also uses the wrongreinitialisation function, which can potentially lead to memorycorruption if there are still waiters on the queue.Not signalling future waiters specifically breaks sound card probedeferrals as codec drivers can not tell that the soundwire device isalready attached when being reprobed. Some codec runtime PMimplementations suffer from similar problems as waiting for enumerationduring resume can also timeout despite the device already having beenenumerated.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:driver: soc: xilinx: use _safe loop iterator to avoid a use after freeThe hash_for_each_possible() loop dereferences "eve_data" to get thenext item on the list. However the loop frees eve_data so it leads toa use after free. Use hash_for_each_possible_safe() instead.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vfio/type1: fix cap_migration information leakFix an information leak where an uninitialized hole in structvfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.The definition of struct vfio_iommu_type1_info_cap_migration contains a hole asshown in this pahole(1) output: struct vfio_iommu_type1_info_cap_migration { struct vfio_info_cap_header header; /* 0 8 */ __u32 flags; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __u64 pgsize_bitmap; /* 16 8 */ __u64 max_dirty_bitmap_size; /* 24 8 */ /* size: 32, cachelines: 1, members: 4 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ };The cap_mig variable is filled in without initializing the hole: static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps) { struct vfio_iommu_type1_info_cap_migration cap_mig; cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION; cap_mig.header.version = 1; cap_mig.flags = 0; /* support minimum pgsize */ cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap); cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX; return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig)); }The structure is then copied to a temporary location on the heap. At this pointit's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspacelater: int vfio_info_add_capability(struct vfio_info_cap *caps, struct vfio_info_cap_header *cap, size_t size) { struct vfio_info_cap_header *header; header = vfio_info_cap_add(caps, size, cap->id, cap->version); if (IS_ERR(header)) return PTR_ERR(header); memcpy(header + 1, cap + 1, size - sizeof(*header)); return 0; }This issue was found by code inspection.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation/dev/vtpmx is made visible before 'workqueue' is initialized, which canlead to a memory corruption in the worst case scenario.Address this by initializing 'workqueue' as the very first step of thedriver initialization.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix a race condition in retrieve_depsThere's a race condition in the multipath target when retrieve_depsraces with multipath_message calling dm_get_device and dm_put_device.retrieve_deps walks the list of open devices without holding any lockbut multipath may add or remove devices to the list while it isrunning. The end result may be memory corruption or use-after-freememory access.See this description of a UAF with multipath_message():https://listman.redhat.com/archives/dm-devel/2022-October/052373.htmlFix this bug by introducing a new rw semaphore "devices_lock". We grabdevices_lock for read in retrieve_deps and we grab it for write indm_get_device and dm_put_device.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: Fix use-after-free in acpi_video_switch_brightness()The switch_brightness_work delayed work accesses device->brightnessand device->backlight, freed by acpi_video_dev_unregister_backlight()during device removal.If the work executes after acpi_video_bus_unregister_backlight()frees these resources, it causes a use-after-free whenacpi_video_switch_brightness() dereferences device->brightness ordevice->backlight.Fix this by calling cancel_delayed_work_sync() for each device'sswitch_brightness_work in acpi_video_bus_remove_notify_handler()after removing the notify handler that queues the work. This ensuresthe work completes before the memory is freed.[ rjw: Changelog edit ]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()Use RCU to avoid a pair of atomic operations and a potentialUAF on dst_dev()->flags.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingThe Supported Rates IE length from an incoming Association Request framewas used directly as the memcpy() length when copying into a fixed-size16-byte stack buffer (supportRate). A malicious station can advertise anIE length larger than 16 bytes, causing a stack buffer overflow.Clamp ie_len to the buffer size before copying the Supported Rates IE,and correct the bounds check when merging Extended Supported Rates toprevent a second potential overflow.This prevents kernel stack corruption triggered by malformed associationrequests.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transferWhen a UAS device is unplugged during data transfer, there isa probability of a system panic occurring. The root cause isan access to an invalid memory address during URB callback handling.Specifically, this happens when the dma_direct_unmap_sg() functionis called within the usb_hcd_unmap_urb_for_dma() interface, but thesg->dma_address field is 0 and the sg data structure has already beenfreed.The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()in uas.c, using the uas_submit_urbs() function to submit requests to USB.Within the uas_submit_urbs() implementation, three URBs (sense_urb,data_urb, and cmd_urb) are sequentially submitted. Device removal mayoccur at any point during uas_submit_urbs execution, which may resultin URB submission failure. However, some URBs might have been successfullysubmitted before the failure, and uas_submit_urbs will return the -ENODEVerror code in this case. The current error handling directly callsscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()to invoke scsi_end_request() for releasing the sgtable. The successfullysubmitted URBs, when being unlinked to giveback, callusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sgunmapping operations since the sg data structure has already been freed.This patch modifies the error condition check in the uas_submit_urbs()function. When a UAS device is removed but one or more URBs have alreadybeen successfully submitted to USB, it avoids immediately invokingscsi_done() and save the cmnd to devinfo->cmnd array. If the successfullysubmitted URBs is completed before devinfo->resetting being set, thenthe scsi_done() function will be called within uas_try_complete() afterall pending URB operations are finalized. Otherwise, the scsi_done()function will be called within uas_zap_pending(), which is executed afterusb_kill_anchored_urbs().The error handling only takes effect when uas_queuecommand_lck() callsuas_submit_urbs() and returns the error value -ENODEV . In this case,the device is disconnected, and the flow proceeds to uas_disconnect(),where uas_zap_pending() is invoked to call uas_try_complete().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:atm/fore200e: Fix possible data race in fore200e_open()Protect access to fore200e->available_cell_rate with rate_mtx lock in theerror handling path of fore200e_open() to prevent a data race.The field fore200e->available_cell_rate is a shared resource used to trackavailable bandwidth. It is concurrently accessed by fore200e_open(),fore200e_close(), and fore200e_change_qos().In fore200e_open(), the lock rate_mtx is correctly held when subtractingvcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.However, if the subsequent call to fore200e_activate_vcin() fails, thefunction restores the reserved bandwidth by adding back toavailable_cell_rate without holding the lock.This introduces a race condition because available_cell_rate is a globaldevice resource shared across all VCCs. If the error path infore200e_open() executes concurrently with operations likefore200e_close() or fore200e_change_qos() on other VCCs, aread-modify-write race occurs.Specifically, the error path reads the rate without the lock. If anotherCPU acquires the lock and modifies the rate (e.g., releasing bandwidth infore200e_close()) between this read and the subsequent write, the errorpath will overwrite the concurrent update with a stale value. This resultsin incorrect bandwidth accounting.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/poll: correctly handle io_poll_add() return value on updateWhen the core of io_uring was updated to handle completionsconsistently and with fixed return codes, the POLL_REMOVE opcodewith updates got slightly broken. If a POLL_ADD is pending andthen POLL_REMOVE is used to update the events of that request, if thatupdate causes the POLL_ADD to now trigger, then that completion is lostand a CQE is never posted.Additionally, ensure that if an update does cause an existing POLL_ADDto complete, that the completion value isn't always overwritten with-ECANCELED. For that case, whatever io_poll_add() set the value toshould just be retained.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_ptp_openWhen kvzalloc_node or kvzalloc failed in mlx5e_ptp_open, the memorypointed by "c" or "cparams" is not freed, which can lead to a memoryleak. Fix by freeing the array in the error path.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_pmem: add the missing REQ_OP_WRITE for flush bioWhen doing mkfs.xfs on a pmem device, the following warning was ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ #154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60The root cause is that submit_bio_noacct() needs bio_op() is eitherWRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assignREQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just failthe flush bio.Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And wecould fix the flush order issue and do flush optimization later.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: fsl_upm: Fix an off-by one test in fun_exec_op()'op-cs' is copied in 'fun->mchip_number' which is used to access the'mchip_offsets' and the 'rnb_gpio' arrays.These arrays have NAND_MAX_CHIPS elements, so the index must be below thislimit.Fix the sanity check in order to avoid the NAND_MAX_CHIPS value. Thiswould lead to out-of-bound accesses.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:sh: dma: Fix DMA channel offset calculationVarious SoCs of the SH3, SH4 and SH4A family, which use this driver,feature a differing number of DMA channels, which can be distributedbetween up to two DMAC modules. The existing implementation fails tocorrectly accommodate for all those variations, resulting in wrongchannel offset calculations and leading to kernel panics.Rewrite dma_base_addr() in order to properly calculate channel offsetsin a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so thatthe correct DMAC module base is selected for the DMAOR register.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fixup btree_cache_wait list damageWe get a kernel crash about "list_add corruption. next->prev should beprev (ffff9c801bc01210), but was ffff9c77b688237c.(next=ffffae586d8afe68)."crash> struct list_head 0xffff9c801bc01210struct list_head { next = 0xffffae586d8afe68, prev = 0xffffae586d8afe68}crash> struct list_head 0xffff9c77b688237cstruct list_head { next = 0x0, prev = 0x0}crash> struct list_head 0xffffae586d8afe68struct list_head struct: invalid kernel virtual address: ffffae586d8afe68 type: "gdb_readmem_callback"Cannot access memory at address 0xffffae586d8afe68[230469.019492] Call Trace:[230469.032041] prepare_to_wait+0x8a/0xb0[230469.044363] ? bch_btree_keys_free+0x6c/0xc0 [escache][230469.056533] mca_cannibalize_lock+0x72/0x90 [escache][230469.068788] mca_alloc+0x2ae/0x450 [escache][230469.080790] bch_btree_node_get+0x136/0x2d0 [escache][230469.092681] bch_btree_check_thread+0x1e1/0x260 [escache][230469.104382] ? finish_wait+0x80/0x80[230469.115884] ? bch_btree_check_recurse+0x1a0/0x1a0 [escache][230469.127259] kthread+0x112/0x130[230469.138448] ? kthread_flush_work_fn+0x10/0x10[230469.149477] ret_from_fork+0x35/0x40bch_btree_check_thread() and bch_dirty_init_thread() may callmca_cannibalize() to cannibalize other cached btree nodes. Only one threadcan do it at a time, so the op of other threads will be added to thebtree_cache_wait list.We must call finish_wait() to remove op from btree_cache_wait before freeit's memory address. Otherwise, the list will be damaged. Also should callbch_cannibalize_unlock() to release the btree_cache_alloc_lock and wake_upother waiters.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix data race on CQP completion statsCQP completion statistics is read lockesly in irdma_wait_event andirdma_check_cqp_progress while it can be updated in the completionthread irdma_sc_ccq_get_cqe_info on another CPU as KCSAN reports.Make completion statistics an atomic variable to reflect coherent updatesto it. This will also avoid load/store tearing logic bug potentiallypossible by compiler optimizations.[77346.170861] BUG: KCSAN: data-race in irdma_handle_cqp_op [irdma] / irdma_sc_ccq_get_cqe_info [irdma][77346.171383] write to 0xffff8a3250b108e0 of 8 bytes by task 9544 on cpu 4:[77346.171483] irdma_sc_ccq_get_cqe_info+0x27a/0x370 [irdma][77346.171658] irdma_cqp_ce_handler+0x164/0x270 [irdma][77346.171835] cqp_compl_worker+0x1b/0x20 [irdma][77346.172009] process_one_work+0x4d1/0xa40[77346.172024] worker_thread+0x319/0x700[77346.172037] kthread+0x180/0x1b0[77346.172054] ret_from_fork+0x22/0x30[77346.172136] read to 0xffff8a3250b108e0 of 8 bytes by task 9838 on cpu 2:[77346.172234] irdma_handle_cqp_op+0xf4/0x4b0 [irdma][77346.172413] irdma_cqp_aeq_cmd+0x75/0xa0 [irdma][77346.172592] irdma_create_aeq+0x390/0x45a [irdma][77346.172769] irdma_rt_init_hw.cold+0x212/0x85d [irdma][77346.172944] irdma_probe+0x54f/0x620 [irdma][77346.173122] auxiliary_bus_probe+0x66/0xa0[77346.173137] really_probe+0x140/0x540[77346.173154] __driver_probe_device+0xc7/0x220[77346.173173] driver_probe_device+0x5f/0x140[77346.173190] __driver_attach+0xf0/0x2c0[77346.173208] bus_for_each_dev+0xa8/0xf0[77346.173225] driver_attach+0x29/0x30[77346.173240] bus_add_driver+0x29c/0x2f0[77346.173255] driver_register+0x10f/0x1a0[77346.173272] __auxiliary_driver_register+0xbc/0x140[77346.173287] irdma_init_module+0x55/0x1000 [irdma][77346.173460] do_one_initcall+0x7d/0x410[77346.173475] do_init_module+0x81/0x2c0[77346.173491] load_module+0x1232/0x12c0[77346.173506] __do_sys_finit_module+0x101/0x180[77346.173522] __x64_sys_finit_module+0x3c/0x50[77346.173538] do_syscall_64+0x39/0x90[77346.173553] entry_SYSCALL_64_after_hwframe+0x63/0xcd[77346.173634] value changed: 0x0000000000000094 -> 0x0000000000000095
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:samples/bpf: Fix buffer overflow in tcp_baserttUsing sizeof(nv) or strlen(nv)+1 is correct.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:refscale: Fix uninitalized use of wait_queue_head_tRunning the refscale test occasionally crashes the kernel with thefollowing error:[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8[ 8569.952900] #PF: supervisor read access in kernel mode[ 8569.952902] #PF: error_code(0x0000) - not-present page[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 :[ 8569.952940] Call Trace:[ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale][ 8569.952959] kthread+0x10e/0x130[ 8569.952966] ret_from_fork+0x1f/0x30[ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call tothe torture_create_kthread() function that creates the ref_scale_readerkthread. Although this init_waitqueue_head() call will very likelycomplete before this kthread is created and starts running, it ispossible that the calling kthread will be delayed between the calls totorture_create_kthread() and init_waitqueue_head(). In this case, thenew kthread will use the waitqueue head before it is properly initialized,which is not good for the kernel's health and well-being.The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash hereThe offset of flags from list_head entry in wait_queue_entry is-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_taskstructure is zero initialized, the instruction will try to access address0xffffffffffffffe8, which is exactly the fault address listed above.This commit therefore invokes init_waitqueue_head() before creatingthe kthread.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix invalid inode pointer dereferences during log replayIn a few places where we call read_one_inode(), if we get a NULL pointerwe end up jumping into an error path, or fallthrough in case of__add_inode_ref(), where we then do something like this: iput(&inode->vfs_inode);which results in an invalid inode pointer that triggers an invalid memoryaccess, resulting in a crash.Fix this by making sure we don't do such dereferences.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: guard against EA inode refcount underflow in xattr updatesyzkaller found a path where ext4_xattr_inode_update_ref() reads an EAinode refcount that is already <= 0 and then applies ref_change (often-1). That lets the refcount underflow and we proceed with a bogus value,triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117Make the invariant explicit: if the current refcount is non-positive,treat this as on-disk corruption, emit ext4_error_inode(), and fail theoperation with -EFSCORRUPTED instead of updating the refcount. Delete theWARN_ONCE() as negative refcounts are now impossible; keep error reportingin ext4_error_inode().This prevents the underflow and the follow-on orphan/cleanup churn.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadgetIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadgetstructure (pdev->gadget) was freed before its endpoints.The endpoints are linked via the ep_list in the gadget structure.Freeing the gadget first leaves dangling pointers in the endpoint list.When the endpoints are subsequently freed, this results in a use-after-free.Fix:By separating the usb_del_gadget_udc() operation into distinct "del" and"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to thefinal release of the gadget structure with usb_put_gadget().A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Add RDSEED fix for Zen5There's an issue with RDSEED's 16-bit and 32-bit register outputvariants on Zen5 which return a random value of 0 "at a rate inconsistentwith randomness while incorrectly signaling success (CF=1)". Search theweb for AMD-SB-7055 for more detail.Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: stratix10-svc: fix bug in saving controller dataFix the incorrect usage of platform_set_drvdata and dev_set_drvdata. Theyboth are of the same data and overrides each other. This resulted in thermmod of the svc driver to fail and throw a kernel panic for kthread_stopand fifo free.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP eventsThe DSP event handling code in hwdep_read() could write more bytes tothe user buffer than requested, when a user provides a buffer smallerthan the event header size (8 bytes).Fix by using min_t() to clamp the copy size, This ensures we never copymore than the user requested.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led-bl: Add devlink to supplier LEDsLED Backlight is a consumer of one or multiple LED class devices, butdevlink is currently unable to create correct supplier-producer links whenthe supplier is a class device. It creates instead a link where thesupplier is the parent of the expected device.One consequence is that removal order is not correctly enforced.Issues happen for example with the following sections in a device treeoverlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; };In this example, the devlink should be created between the backlight-addon(consumer) and the pca9632@62 (supplier). Instead it is created between thebacklight-addon (consumer) and the parent of the pca9632@62, which istypically the I2C bus adapter.On removal of the above overlay, the LED driver can be removed before thebacklight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98Another way to reproduce the bug without any device tree overlays isunbinding the LED class device (pca9632@62) before unbinding the consumer(backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbindFix by adding a devlink between the consuming led-backlight device and thesupplying LED device, as other drivers and subsystems do as well.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: avoid kernel-infoleak from struct iw_pointstruct iw_point has a 32bit hole on 64bit arches.struct iw_point { void __user *pointer; /* Pointer to the data (in user space) */ __u16 length; /* number of fields or size in bytes */ __u16 flags; /* Optional params */};Make sure to zero the structure to avoid disclosing 32bits of kernel datato user space.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD inresponse to a guest WRMSR, clear XFD-disabled features in the saved (or tobe restored) XSTATE_BV to ensure KVM doesn't attempt to load state forfeatures that are disabled via the guest's XFD. Because the kernelexecutes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1will cause XRSTOR to #NM and panic the kernel.E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]---This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler'scall to fpu_update_guest_xfd().and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]---The new behavior is consistent with the AMX architecture. Per Intel's SDM,XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD(and non-compacted XSAVE saves the initial configuration of the statecomponent): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by usinga constant XFD based on the set of enabled features when XSAVEing fora struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabledfeatures can only happen in the above interrupt case, or in similarscenarios involving preemption on preemptible kernels, becausefpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves theoutgoing FPU state with the current XFD; and that is (on all but thefirst WRMSR to XFD) the guest XFD.Therefore, XFD can only go out of sync with XSTATE_BV in the aboveinterrupt case, or in similar scenarios involving preemption onpreemptible kernels, and it we can consider it (de facto) part of KVMABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.[Move clea---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: fix received length check in big packetsSince commit 4959aebba8c0 ("virtio-net: use mtu size as buffer lengthfor big packets"), when guest gso is off, the allocated size for bigpackets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends onnegotiated MTU. The number of allocated frags for big packets is storedin vi->big_packets_num_skbfrags.Because the host announced buffer length can be malicious (e.g. the hostvhost_net driver's get_rx_bufs is modified to announce incorrectlength), we need a check in virtio_net receive path. Currently, thecheck is not adapted to the new change which can lead to NULL pagepointer dereference in the below while loop when receiving length thatis larger than the allocated one.This commit fixes the received length check corresponding to the newchange.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: account for current allocated stack depth in widen_imprecise_scalars()The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);Where prev_st is an ancestor of the queued_st in the explored statestree. This ancestor is not guaranteed to have same allocated stackdepth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loopHere, for a second 'foo' call prev_st->allocated_stack is 128,while queued_st->allocated_stack is much smaller.widen_imprecise_scalars() needs to take this into account and avoidaccessing bpf_verifier_state->frame[*]->stack out of bounds.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix improper freeing of purex itemIn qla2xxx_process_purls_iocb(), an item is allocated viaqla27xx_copy_multiple_pkt(), which internally callsqla24xx_alloc_purex_item().The qla24xx_alloc_purex_item() function may return a pre-allocated itemfrom a per-adapter pool for small allocations, instead of dynamicallyallocating memory with kzalloc().An error handling path in qla2xxx_process_purls_iocb() incorrectly useskfree() to release the item. If the item was from the pre-allocatedpool, calling kfree() on it is a bug that can lead to memory corruption.Fix this by using the correct deallocation function,qla24xx_free_purex_item(), which properly handles both dynamicallyallocated and pre-allocated items.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:inet: frags: flush pending skbs in fqdir_pre_exit()We have been seeing occasional deadlocks on pernet_ops_rwsem sinceSeptember in NIPA. The stuck task was usually modprobe (often loadinga driver like ipvlan), trying to take the lock as a Writer.lockdep does not track readers for rwsems so the read wasn't obviousfrom the reports.On closer inspection the Reader holding the lock was conntrack loopingforever in nf_conntrack_cleanup_net_list(). Based on past experiencewith occasional NIPA crashes I looked thru the tests which run beforethe crash and noticed that the crash follows ip_defrag.sh. An immediatered flag. Scouring thru (de)fragmentation queues reveals skbs sittingaround, holding conntrack references.The problem is that since conntrack depends on nf_defrag_ipv6,nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first itsnetns exit hooks run _after_ conntrack's netns exit hook.Flush all fragment queue SKBs during fqdir_pre_exit() to releaseconntrack references before conntrack cleanup runs. Also flushthe queues in timer expiry handlers when they discover fqdir->deadis set, in case packet sneaks in while we're running the pre_exitflush.The commit under Fixes is not exactly the culprit, but I thinkpreviously the timer firing would eventually unblock the spinningconntrack.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix XDP_TX pathFor XDP_TX action in bnxt_rx_xdp(), clearing of the event flags is notcorrect. __bnxt_poll_work() -> bnxt_rx_pkt() -> bnxt_rx_xdp() may belooping within NAPI and some event flags may be set in earlieriterations. In particular, if BNXT_TX_EVENT is set earlier indicatingsome XDP_TX packets are ready and pending, it will be cleared if it isXDP_TX action again. Normally, we will set BNXT_TX_EVENT again when wesuccessfully call __bnxt_xmit_xdp(). But if the TX ring has no moreroom, the flag will not be set. This will cause the TX producer to beahead but the driver will not hit the TX doorbell.For multi-buf XDP_TX, there is no need to clear the event flags and setBNXT_AGG_EVENT. The BNXT_AGG_EVENT flag should have been set earlier inbnxt_rx_pkt().The visible symptom of this is that the RX ring associated with theTX XDP ring will eventually become empty and all packets will be dropped.Because this condition will cause the driver to not refill the RX ringseeing that the TX ring has forever pending XDP_TX packets.The fix is to only clear BNXT_RX_EVENT when we have successfullycalled __bnxt_xmit_xdp().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
gpg2 > 0-0 (version in image is 2.4.4-slfo.1.1_7.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fallback earlier on simult connectionSyzkaller reports a simult-connect race leading to inconsistent fallbackstatus: WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Modules linked in: CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 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/2014 RIP: 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900 R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197 tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922 tcp_v6_do_rcv+0x492/0x1740 net/ipv6/tcp_ipv6.c:1672 tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918 ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1e4/0x4b0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500 dst_input include/net/dst.h:471 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x264/0x650 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979 __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092 process_backlog+0x442/0x15e0 net/core/dev.c:6444 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494 napi_poll net/core/dev.c:7557 [inline] net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684 handle_softirqs+0x216/0x8e0 kernel/softirq.c:579 run_ksoftirqd kernel/softirq.c:968 [inline] run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread.c:463 ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 The TCP subflow can process the simult-connect syn-ack packet aftertransitioning to TCP_FIN1 state, bypassing the MPTCP fallback check,as the sk_state_change() callback is not invoked for * -> FIN_WAIT1transitions.That will move the msk socket to an inconsistent status and the nextincoming data will hit the reported splat.Close the race moving the simult-fallback check at the earliest possiblestage - that is at syn-ack generation time.About the fixes tags: [2] was supposed to also fix this issue introducedby [3]. [1] is required as a dependence: it was not explicitly marked asa fix, but it is one and it has already been backported before [3]. Inother words, this commit should be backported up to [3], including [2]and [1] if that's not already there.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
libxml2-2 > 0-0 (version in image is 2.11.6-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:arp: do not assume dev_hard_header() does not change skb->headarp_create() is the only dev_hard_header() callermaking assumption about skb->head being unchanged.A recent commit broke this assumption.Initialize @arp pointer after dev_hard_header() call.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix double-free in nr_route_frame()In nr_route_frame(), old_skb is immediately freed without checking ifnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,the caller function will free old_skb again, causing a double-free bug.Therefore, to prevent this, we need to modify it to check whethernr_neigh->ax25 is NULL before freeing old_skb.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
python311-cryptography > 0-0 (version in image is 42.0.4-slfo.1.1_2.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addressesWhen using the felix driver (the only one which supports UC filteringand MC filtering) as a DSA master for a random other DSA switch, one cansee the following stack trace when the downstream switch ports join aVLAN-aware bridge:=============================WARNING: suspicious RCU usage-----------------------------net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!stack backtrace:Workqueue: dsa_ordered dsa_slave_switchdev_event_workCall trace: lockdep_rcu_suspicious+0x170/0x210 vlan_for_each+0x8c/0x188 dsa_slave_sync_uc+0x128/0x178 __hw_addr_sync_dev+0x138/0x158 dsa_slave_set_rx_mode+0x58/0x70 __dev_set_rx_mode+0x88/0xa8 dev_uc_add+0x74/0xa0 dsa_port_bridge_host_fdb_add+0xec/0x180 dsa_slave_switchdev_event_work+0x7c/0x1c8 process_one_work+0x290/0x568What it's saying is that vlan_for_each() expects rtnl_lock() context andit's not getting it, when it's called from the DSA master's ndo_set_rx_mode().The caller of that - dsa_slave_set_rx_mode() - is the slave DSAinterface's dsa_port_bridge_host_fdb_add() which comes from the deferreddsa_slave_switchdev_event_work().We went to great lengths to avoid the rtnl_lock() context in that callpath in commit 0faf890fc519 ("net: dsa: drop rtnl_lock fromdsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply notan option due to the possibility of deadlocking when callingdsa_flush_workqueue() from the call paths that do hold rtnl_lock() -basically all of them.So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(),the state of the 8021q driver on this device is really not protectedfrom concurrent access by anything.Looking at net/8021q/, I don't think that vlan_info->vid_list wasparticularly designed with RCU traversal in mind, so introducing an RCUread-side form of vlan_for_each() - vlan_for_each_rcu() - won't be soeasy, and it also wouldn't be exactly what we need anyway.In general I believe that the solution isn't in net/8021q/ anyway;vlan_for_each() is not cut out for this task. DSA doesn't need rtnl_lock()to be held per se - since it's not a netdev state change that we'reblocking, but rather, just concurrent additions/removals to a VLAN list.We don't even need sleepable context - the callback of vlan_for_each()just schedules deferred work.The proposed escape is to remove the dependency on vlan_for_each() andto open-code a non-sleepable, rtnl-free alternative to that, based oncopies of the VLAN list modified from .ndo_vlan_rx_add_vid() and.ndo_vlan_rx_kill_vid().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/efa: Fix wrong resources deallocation orderWhen trying to destroy QP or CQ, we first decrease the refcount andpotentially free memory regions allocated for the object and thenrequest the device to destroy the object. If the device fails, theobject isn't fully destroyed so the user/IB core can try to destroy theobject again which will lead to underflow when trying to decrease analready zeroed refcount.Deallocate resources in reverse order of allocating them to safely freethem.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix data race on CQP request doneKCSAN detects a data race on cqp_request->request_done memory locationwhich is accessed locklessly in irdma_handle_cqp_op while beingupdated in irdma_cqp_ce_handler.Annotate lockless intent with READ_ONCE/WRITE_ONCE to avoid anycompiler optimizations like load fusing and/or KCSAN warning.[222808.417128] BUG: KCSAN: data-race in irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma][222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5:[222808.417610] irdma_cqp_ce_handler+0x21e/0x270 [irdma][222808.417725] cqp_compl_worker+0x1b/0x20 [irdma][222808.417827] process_one_work+0x4d1/0xa40[222808.417835] worker_thread+0x319/0x700[222808.417842] kthread+0x180/0x1b0[222808.417852] ret_from_fork+0x22/0x30[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1:[222808.417995] irdma_wait_event+0x1e2/0x2c0 [irdma][222808.418099] irdma_handle_cqp_op+0xae/0x170 [irdma][222808.418202] irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma][222808.418308] irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma][222808.418411] irdma_rt_deinit_hw+0x179/0x1d0 [irdma][222808.418514] irdma_ib_dealloc_device+0x11/0x40 [irdma][222808.418618] ib_dealloc_device+0x2a/0x120 [ib_core][222808.418823] __ib_unregister_device+0xde/0x100 [ib_core][222808.418981] ib_unregister_device+0x22/0x40 [ib_core][222808.419142] irdma_ib_unregister_device+0x70/0x90 [irdma][222808.419248] i40iw_close+0x6f/0xc0 [irdma][222808.419352] i40e_client_device_unregister+0x14a/0x180 [i40e][222808.419450] i40iw_remove+0x21/0x30 [irdma][222808.419554] auxiliary_bus_remove+0x31/0x50[222808.419563] device_remove+0x69/0xb0[222808.419572] device_release_driver_internal+0x293/0x360[222808.419582] driver_detach+0x7c/0xf0[222808.419592] bus_remove_driver+0x8c/0x150[222808.419600] driver_unregister+0x45/0x70[222808.419610] auxiliary_driver_unregister+0x16/0x30[222808.419618] irdma_exit_module+0x18/0x1e [irdma][222808.419733] __do_sys_delete_module.constprop.0+0x1e2/0x310[222808.419745] __x64_sys_delete_module+0x1b/0x30[222808.419755] do_syscall_64+0x39/0x90[222808.419763] entry_SYSCALL_64_after_hwframe+0x63/0xcd[222808.419829] value changed: 0x01 -> 0x03
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: ipc: fix use-after-free in ipc_msg_send_requestipc_msg_send_request() waits for a generic netlink reply using anipc_msg_table_entry on the stack. The generic netlink handler(handle_generic_event()/handle_response()) fills entry->response underipc_msg_table_lock, but ipc_msg_send_request() used to validate and freeentry->response without holding the same lock.Under high concurrency this allows a race where handle_response() iscopying data into entry->response while ipc_msg_send_request() has justfreed it, leading to a slab-use-after-free reported by KASAN inhandle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]Fix by:- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table.- Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock.- Returning NULL in the error path, preserving the original API semantics.This makes all accesses to entry->response consistent withhandle_response(), which already updates and fills the response bufferunder ipc_msg_table_lock, and closes the race that allowed the UAF.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()In iscsit_dec_session_usage_count(), the function calls complete() whileholding the sess->session_usage_lock. Similar to the connection usage countlogic, the waiter signaled by complete() (e.g., in the session releasepath) may wake up and free the iscsit_session structure immediately.This creates a race condition where the current thread may attempt toexecute spin_unlock_bh() on a session structure that has already beendeallocated, resulting in a KASAN slab-use-after-free.To resolve this, release the session_usage_lock before calling complete()to ensure all dereferences of the sess pointer are finished before thewaiter is allowed to proceed with deallocation.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()and/or mptcp_pm_nl_is_backup()Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()which is not RCU ready.list_splice_init_rcu() can not be called here while holding pernet->lockspinlock.Many thanks to Eulgyu Kim for providing a repro and testing our patches.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/stm: ltdc: fix late dereference checkIn ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in acontainer_of() before the pointer check. This could cause a kernel panic.Fix this smatch warning:drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Free released resource after coalescingrelease_resource() doesn't actually free the resource or resource listentry so free the resource list entry to avoid a leak.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: freescale: Fix a memory out of bounds when num_configs is 1The config passed in by pad wakeup is 1, when num_configs is 1,Configuration [1] should not be fetched, which will be detectedby KASAN as a memory out of bounds condition. Modify to getconfigs[1] when num_configs is 2.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: deal with integer overflows in kmalloc_reserve()Blamed commit changed: ptr = kmalloc(size); if (ptr) size = ksize(ptr); size = kmalloc_size_roundup(size); ptr = kmalloc(size);This allowed various crash as reported by syzbot [1]and Kyle Zeng.Problem is that if @size is bigger than 0x80000001,kmalloc_size_roundup(size) returns 2^32.kmalloc_reserve() uses a 32bit variable (obj_size),so 2^32 is truncated to 0.kmalloc(0) returns ZERO_SIZE_PTR which is not handled byskb allocations.Following trace can be triggered if a netdev->mtu is setclose to 0x7fffffffWe might in the future limit netdev->mtu to more sensiblelimit (like KMALLOC_MAX_SIZE).This patch is based on a syzbot report, and also a reportand tentative fix from Kyle Zeng.[1]BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023Call trace:dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286__dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106print_report+0xe4/0x4b4 mm/kasan/report.c:398kasan_report+0x150/0x1ac mm/kasan/report.c:495kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189memset+0x40/0x70 mm/kasan/shadow.c:44__build_skb_around net/core/skbuff.c:294 [inline]__alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527alloc_skb include/linux/skbuff.h:1316 [inline]igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359add_grec+0x81c/0x1124 net/ipv4/igmp.c:534igmpv3_send_cr net/ipv4/igmp.c:667 [inline]igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474expire_timers kernel/time/timer.c:1519 [inline]__run_timers+0x54c/0x710 kernel/time/timer.c:1790run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803_stext+0x380/0xfbc____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84invoke_softirq kernel/softirq.c:437 [inline]__irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683irq_exit_rcu+0x14/0x78 kernel/softirq.c:695el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717__el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_syncUse-after-free can occur in hci_disconnect_all_sync if a connection isdeleted by concurrent processing of a controller event.To prevent this the code now tries to iterate over the list backwardsto ensure the links are cleanup before its parents, also it no longerrelies on a cursor, instead it always uses the last element sincehci_abort_conn_sync is guaranteed to call hci_conn_del.UAF crash log:==================================================================BUG: KASAN: slab-use-after-free in hci_set_powered_sync(net/bluetooth/hci_sync.c:5424) [bluetooth]Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W6.5.0-rc1+ #10Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.16.2-1.fc38 04/01/2014Workqueue: hci0 hci_cmd_sync_work [bluetooth]Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xdd/0x160 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] kasan_report+0xa6/0xe0 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_cmd_sync_work+0x137/0x220 [bluetooth] process_one_work+0x526/0x9d0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x1a/0x90 worker_thread+0x92/0x630 ? __pfx_worker_thread+0x10/0x10 kthread+0x196/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 Allocated by task 1782: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 hci_conn_add+0xa5/0xa80 [bluetooth] hci_bind_cis+0x881/0x9b0 [bluetooth] iso_connect_cis+0x121/0x520 [bluetooth] iso_sock_connect+0x3f6/0x790 [bluetooth] __sys_connect+0x109/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 695: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10a/0x180 __kmem_cache_free+0x14d/0x2e0 device_release+0x5d/0xf0 kobject_put+0xdf/0x270 hci_disconn_complete_evt+0x274/0x3a0 [bluetooth] hci_event_packet+0x579/0x7e0 [bluetooth] hci_rx_work+0x287/0xaa0 [bluetooth] process_one_work+0x526/0x9d0 worker_thread+0x92/0x630 kthread+0x196/0x1e0 ret_from_fork+0x2c/0x50==================================================================
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:regmap-irq: Fix out-of-bounds access when allocating config buffersWhen allocating the 2D array for handling IRQ type registers inregmap_add_irq_chip_fwnode(), the intent is to allocate a matrixwith num_config_bases rows and num_config_regs columns.This is currently handled by allocating a buffer to hold a pointer foreach row (i.e. num_config_bases). After that, the logic attempts toallocate the memory required to hold the register configuration foreach row. However, instead of doing this allocation for each row(i.e. num_config_bases allocations), the logic erroneously does thisallocation num_config_regs number of times.This scenario can lead to out-of-bounds accesses when num_config_regsis greater than num_config_bases. Fix this by updating the terminatingcondition of the loop that allocates the memory for holding the registerconfiguration to allocate memory only for each row in the matrix.Amit Pundir reported a crash that was occurring on his db845c devicedue to memory corruption (see "Closes" tag for Amit's report). The KASANreport below helped narrow it down to this issue:[ 14.033877][ T1] ==================================================================[ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364[ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1[ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850[ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8[ 14.255669][ T1] The buggy address is located 0 bytes inside of[ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Clean up integer overflow checking in map_user_pages()The encode_dma() function has some validation on in_trans->size but itwould be more clear to move those checks to find_and_map_user_pages().The encode_dma() had two checks: if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL;The in_trans->addr variable is the starting address. The in_trans->sizevariable is the total size of the transfer. The transfer can occur inparts and the resources->xferred_dma_size tracks how many bytes we havealready transferred.This patch introduces a new variable "remaining" which represents theamount we want to transfer (in_trans->size) minus the amount we havealready transferred (resources->xferred_dma_size).I have modified the check for if in_trans->size is zero to instead checkif in_trans->size is less than resources->xferred_dma_size. If we havealready transferred more bytes than in_trans->size then there are negativebytes remaining which doesn't make sense. If there are zero bytesremaining to be copied, just return success.The check in encode_dma() checked that "addr + size" could not overflowand barring a driver bug that should work, but it's easier to check ifwe do this in parts. First check that "in_trans->addr +resources->xferred_dma_size" is safe. Then check that "xfer_start_addr +remaining" is safe.My final concern was that we are dealing with u64 values but on 32bitsystems the kmalloc() function will truncate the sizes to 32 bits. SoI calculated "total = in_trans->size + offset_in_page(xfer_start_addr);"and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bitsystems.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: dw_hdmi: fix connector access for scdcCommit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdcinterface to pick up an i2c adapter from a connector instead. However, inthe case of dw-hdmi, the wrong connector was being used to pass i2c adapterinformation, since dw-hdmi's embedded connector structure is only populatedwhen the bridge attachment callback explicitly asks for it.drm-meson is handling connector creation, so this won't happen, leading toa NULL pointer dereference.Fix it by having scdc functions access dw-hdmi's current connector pointerinstead, which is assigned during the bridge enablement stage.[narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: don't assume adequate headroom for SDIO headersmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() andmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume thatadequate headroom will be available in the passed skb. This assumptiontypically is satisfied when the skb was allocated in the net core fortransmission via the mt7921 netdev (although even that is only anoptimization and is not strictly guaranteed), but the assumption issometimes not satisfied when the skb originated in the receive path ofanother netdev and was passed through to the mt7921, such as by thebridge layer. Blindly prepending bytes to an skb is always wrong.This commit introduces a call to skb_cow_head() before the call tomt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() toensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can bepushed onto the skb.Without this fix, I can trivially cause kernel panics by bridging anMT7921AU-based USB 802.11ax interface with an Ethernet interface on anIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernetadapter and also on an ARM-based Raspberry Pi 1 using its onboardSMSC9512 USB Ethernet adapter. Note that the panics do not occur inevery system configuration, as they occur only if the receiving netdevleaves less headroom in its received skbs than the mt7921 needs for itsSDIO headers.Here is an example stack trace of this panic on Raspberry Pi OS Lite2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34After this fix, bridging the mt7921 interface works fine on both of mypreviously problematic systems.[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:regulator: da9063: fix null pointer deref with partial DT configWhen some of the da9063 regulators do not have corresponding DT nodesa null pointer dereference occurs on boot because such regulators haveno init_data causing the pointers calculated inda9063_check_xvp_constraints() to be invalid.Do not dereference them in this case.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix warning for holder mismatch from export_rdev()Commit a1d767191096 ("md: use mddev->external to select holder inexport_rdev()") fix the problem that 'claim_rdev' is used forblkdev_get_by_dev() while 'rdev' is used for blkdev_put().However, if mddev->external is changed from 0 to 1, then 'rdev' is usedfor blkdev_get_by_dev() while 'claim_rdev' is used for blkdev_put(). Andthis problem can be reporduced reliably by following:New file: mdadm/tests/23rdev-lifetimedevname=${dev0##*/}devt=`cat /sys/block/$devname/dev`pid=""runtime=2clean_up_test() { pill -9 $pid echo clear > /sys/block/md0/md/array_state}trap 'clean_up_test' EXITadd_by_sysfs() { while true; do echo $devt > /sys/block/md0/md/new_dev done}remove_by_sysfs(){ while true; do echo remove > /sys/block/md0/md/dev-${devname}/state done}echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"add_by_sysfs &pid="$pid $!"remove_by_sysfs &pid="$pid $!"sleep $runtimeexit 0Test cmd:./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetimeTest result:------------[ cut here ]------------WARNING: CPU: 0 PID: 960 at block/bdev.c:618 blkdev_put+0x27c/0x330Modules linked in: multipath md_mod loopCPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50RIP: 0010:blkdev_put+0x27c/0x330Call Trace: export_rdev.isra.23+0x50/0xa0 [md_mod] mddev_unlock+0x19d/0x300 [md_mod] rdev_attr_store+0xec/0x190 [md_mod] sysfs_kf_write+0x52/0x70 kernfs_fop_write_iter+0x19a/0x2a0 vfs_write+0x3b5/0x770 ksys_write+0x74/0x150 __x64_sys_write+0x22/0x30 do_syscall_64+0x40/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdFix the problem by recording if 'rdev' is used as holder.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-core: fix memory leak in dhchap_ctrl_secretFree dhchap_secret in nvme_ctrl_dhchap_ctrl_secret_store() before wereturn when nvme_auth_generate_key() returns error.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:perf tool x86: Fix perf_env memory leakFound by leak sanitizer:```==1632594==ERROR: LeakSanitizer: detected memory leaksDirect leak of 21 byte(s) in 1 object(s) allocated from: #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439 #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369 #2 0x556701d70589 in perf_env__cpuid util/env.c:465 #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14 #4 0x5567020487a2 in arch__post_evsel_config arch/x86/util/evsel.c:83 #5 0x556701d8f78b in evsel__config util/evsel.c:1366 #6 0x556701ef5872 in evlist__config util/record.c:108 #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112 #8 0x556701cacd07 in run_test tests/builtin-test.c:236 #9 0x556701cacfac in test_and_print tests/builtin-test.c:265 #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402 #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559 #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323 #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377 #14 0x556701d3be90 in run_argv tools/perf/perf.c:421 #15 0x556701d3c3f8 in main tools/perf/perf.c:537 #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).```
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: IOMMUFD_DESTROY should not increase the refcountsyzkaller found a race where IOMMUFD_DESTROY increments the refcount: obj = iommufd_get_object(ucmd->ictx, cmd->id, IOMMUFD_OBJ_ANY); if (IS_ERR(obj)) return PTR_ERR(obj); iommufd_ref_to_users(obj); /* See iommufd_ref_to_users() */ if (!iommufd_object_destroy_user(ucmd->ictx, obj))As part of the sequence to join the two existing primitives together.Allowing the refcount the be elevated without holding the destroy_rwsemviolates the assumption that all temporary refcount elevations areprotected by destroy_rwsem. Racing IOMMUFD_DESTROY withiommufd_object_destroy_user() will cause spurious failures: WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478 Modules linked in: CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023 RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477 Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 <0f> 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41 RSP: 0018:ffffc90003067e08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888109ea0300 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000ffffffff RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500 R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88 R13: ffffc90003067ea8 R14: ffff888101249800 R15: 00000000fffffffe FS: 00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555557262da8 CR3: 000000010a6fd000 CR4: 0000000000350ef0 Call Trace: iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline] iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813 iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337 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+0x84/0xc0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe solution is to not increment the refcount on the IOMMUFD_DESTROY pathat all. Instead use the xa_lock to serialize everything. The refcountcheck == 1 and xa_erase can be done under a single critical region. Thisavoids the need for any refcount incrementing.It has the downside that if userspace races destroy with other operationsit will get an EBUSY instead of waiting, but this is kind of racing isalready dangerous.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: Use ktime_t rather than int when dealing with timestampsCode which interacts with timestamps needs to use the ktime_t typereturned by functions like ktime_get. The int type does not offerenough space to store these values, and attempting to use it is arecipe for problems. In this particular case, overflows would occurwhen calculating/storing timestamps leading to incorrect values beingreported to userspace. In some cases these bad timestamps cause inputhandling in userspace to appear hung.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()Smatch detected this potential error pointer dereferenceclk_wzrd_register_divider(). If devm_clk_hw_register() fails thenit sets "hw" to an error pointer and then dereferences it on thenext line. Return the error directly instead.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix rbtree traversal bug in ext4_mb_use_preallocatedDuring allocations, while looking for preallocations(PA) in the perinode rbtree, we can't do a direct traversal of the tree becauseext4_mb_discard_group_preallocation() can paralelly mark the pa deletedand that can cause direct traversal to skip some entries. This wasleading to a BUG_ON() being hit [1] when we missed a PA that could satisfyour request and ultimately tried to create a new PA that would overlapwith the missed one.To makes sure we handle that case while still keeping the performance ofthe rbtree, we make use of the fact that the only pa that could possiblyoverlap the original goal start is the one that satisfies the belowconditions: 1. It must have it's logical start immediately to the left of (ie less than) original logical start. 2. It must not be deletedTo find this pa we use the following traversal method:1. Descend into the rbtree normally to find the immediate neighboringPA. Here we keep descending irrespective of if the PA is deleted or ifit overlaps with our request etc. The goal is to find an immediatelyadjacent PA.2. If the found PA is on right of original goal, use rb_prev() to findthe left adjacent PA.3. Check if this PA is deleted and keep moving left with rb_prev() untila non deleted PA is found.4. This is the PA we are looking for. Now we can check if it can satisfythe original request and proceed accordingly.This approach also takes care of having deleted PAs in the tree.(While we are at it, also fix a possible overflow bug in calculating theend of a PA)[1] https://lore.kernel.org/linux-ext4/CA+G9fYv2FRpLqBZf34ZinR8bU2_ZRAUOjKAD3+tKRFaEQHtt8Q@mail.gmail.com/
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Prevent RT livelock in itimer_delete()itimer_delete() has a retry loop when the timer is concurrently expired. Onnon-RT kernels this just spin-waits until the timer callback has completed,except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORKenabled.In that case and on RT kernels the existing task could live lock whenpreempting the task which does the timer delivery.Replace spin_unlock() with an invocation of timer_wait_running() to handleit the same way as the other retry loops in the posix timer code.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_vti: fix slab-use-after-free in decode_session6When ipv6_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 ipv6_vti device sends IPv6 packets.The stack information is as follows:BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890Read of size 1 at addr ffff88802e08edc2 by task swapper/0/0CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014Call Trace:dump_stack_lvl+0xd9/0x150print_address_description.constprop.0+0x2c/0x3c0kasan_report+0x11d/0x130decode_session6+0x103f/0x1890__xfrm_decode_session+0x54/0xb0vti6_tnl_xmit+0x3e6/0x1ee0dev_hard_start_xmit+0x187/0x700sch_direct_xmit+0x1a3/0xc30__qdisc_run+0x510/0x17a0__dev_queue_xmit+0x2215/0x3b10neigh_connected_output+0x3c2/0x550ip6_finish_output2+0x55a/0x1550ip6_finish_output+0x6b9/0x1270ip6_output+0x1f1/0x540ndisc_send_skb+0xa63/0x1890ndisc_send_rs+0x132/0x6f0addrconf_rs_timer+0x3f1/0x870call_timer_fn+0x1a0/0x580expire_timers+0x29b/0x4b0run_timer_softirq+0x326/0x910__do_softirq+0x1d4/0x905irq_exit_rcu+0xb7/0x120sysvec_apic_timer_interrupt+0x97/0xc0Allocated by task 9176:kasan_save_stack+0x22/0x40kasan_set_track+0x25/0x30__kasan_slab_alloc+0x7f/0x90kmem_cache_alloc_node+0x1cd/0x410kmalloc_reserve+0x165/0x270__alloc_skb+0x129/0x330netlink_sendmsg+0x9b1/0xe30sock_sendmsg+0xde/0x190____sys_sendmsg+0x739/0x920___sys_sendmsg+0x110/0x1b0__sys_sendmsg+0xf7/0x1c0do_syscall_64+0x39/0xb0entry_SYSCALL_64_after_hwframe+0x63/0xcdFreed by task 9176:kasan_save_stack+0x22/0x40kasan_set_track+0x25/0x30kasan_save_free_info+0x2b/0x40____kasan_slab_free+0x160/0x1c0slab_free_freelist_hook+0x11b/0x220kmem_cache_free+0xf0/0x490skb_free_head+0x17f/0x1b0skb_release_data+0x59c/0x850consume_skb+0xd2/0x170netlink_unicast+0x54f/0x7f0netlink_sendmsg+0x926/0xe30sock_sendmsg+0xde/0x190____sys_sendmsg+0x739/0x920___sys_sendmsg+0x110/0x1b0__sys_sendmsg+0xf7/0x1c0do_syscall_64+0x39/0xb0entry_SYSCALL_64_after_hwframe+0x63/0xcdThe buggy address belongs to the object at ffff88802e08ed00which belongs to the cache skbuff_small_head of size 640The buggy address is located 194 bytes inside offreed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:block/rq_qos: protect rq_qos apis with a new lockcommit 50e34d78815e ("block: disable the elevator int del_gendisk")move rq_qos_exit() from disk_release() to del_gendisk(), this willintroduce some problems:1) If rq_qos_add() is triggered by enabling iocost/iolatency through cgroupfs, then it can concurrent with del_gendisk(), it's not safe to write 'q->rq_qos' concurrently.2) Activate cgroup policy that is relied on rq_qos will call rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is called in the middle, null-ptr-dereference will be triggered in blkcg_activate_policy().3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the disk, then if rq_qos_exit() from del_gendisk() is done before rq_qos_add(), then memory will be leaked.This patch add a new disk level mutex 'rq_qos_mutex':1) The lock will protect rq_qos_exit() directly.2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be called from disk initialization for now because wbt can't be destructed until rq_qos_exit(), so it's safe not to protect wbt for now. Hoever, in case that rq_qos dynamically destruction is supported in the furture, this patch also protect rq_qos_add() from wbt_init() directly, this is enough because blk-sysfs already synchronize writers with disk removal.3) For iocost and iolatency, in order to synchronize disk removal and cgroup configuration, the lock is held after blkdev_get_no_open() from blkg_conf_open_bdev(), and is released in blkg_conf_exit(). In order to fix the above memory leak, disk_live() is checked after holding the new lock.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()KSAN reports use-after-free in hci_add_adv_monitor().While adding an adv monitor, hci_add_adv_monitor() calls -> msft_add_monitor_pattern() calls -> msft_add_monitor_sync() calls -> msft_le_monitor_advertisement_cb() calls in an error case -> hci_free_adv_monitor() which frees the *moniter.This is referenced by bt_dev_dbg() in hci_add_adv_monitor().Fix the bt_dev_dbg() by using handle instead of monitor->handle.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ina2xx: avoid NULL pointer dereference on OF device matchThe affected lines were resulting in a NULL pointer dereference on ourplatform because the device tree contained the following list ofcompatible strings: power-sensor@40 { compatible = "ti,ina232", "ti,ina231"; ... };Since the driver doesn't declare a compatible string "ti,ina232", the OFmatching succeeds on "ti,ina231". But the I2C device ID info ispopulated via the first compatible string, cf. modalias population inof_i2c_get_board_info(). Since there is no "ina232" entry in the legacyI2C device ID table either, the struct i2c_device_id *id pointer in theprobe function is NULL.Fix this by using the already populated type variable instead, whichpoints to the proper driver data. Since the name is also wanted, add ageneric one to the ina2xx_config table.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix skb refcnt race after locking changesThere is a race where skb's from the sk_psock_backlog can be referencedafter userspace side has already skb_consumed() the sk_buff and its refcntdropped to zer0 causing use after free.The flow is the following: while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This iswhat the application reads when recvmsg() is called. An application canread this anytime after the msg is placed on the queue. The recvmsg hookwill also read msg->skb and then after user space reads the msg will callconsume_skb(skb) on it effectively free'ing it.But, the race is in above where backlog queue still has a reference tothe skb and calls skb_dequeue(). If the skb_dequeue happens after theuser reads and free's the skb we have a use after free.The !ingress case does not suffer from this problem because it usessendmsg_*(sk, msg) which does not pass the sk_buff further down thestack.The following splat was observed with 'test_progs -t sockmap_listen': [ 1022.710250][ T2556] general protection fault, ... [...] [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80 [ 1022.713653][ T2556] Code: ... [...] [ 1022.720699][ T2556] Call Trace: [ 1022.720984][ T2556] [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0 [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30 [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80 [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300 [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0 [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0 [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10 [ 1022.724386][ T2556] kthread+0xfd/0x130 [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50 [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30 [ 1022.726201][ T2556] To fix we add an skb_get() before passing the skb to be enqueued in theengress queue. This bumps the skb->users refcnt so that consume_skb()and kfree_skb will not immediately free the sk_buff. With this we canbe sure the skb is still around when we do the dequeue. Then we justneed to decrement the refcnt or free the skb in the backlog case whichwe do by calling kfree_skb() on the ingress case as well as the sendmsgcase.Before locking change from fixes tag we had the sock locked so wecouldn't race with user and there was no issue here.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dccp: fix data-race around dp->dccps_mss_cachedccp_sendmsg() reads dp->dccps_mss_cache before locking the socket.Same thing in do_dccp_getsockopt().Add READ_ONCE()/WRITE_ONCE() annotations,and change dccp_sendmsg() to check again dccps_mss_cacheafter socket is locked.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd-mbhc-v2: fix resource leaks on component removeThe MBHC resources must be released on component probe failure andremoval so can not be tied to the lifetime of the component device.This is specifically needed to allow probe deferrals of the sound cardwhich otherwise fails when reprobing the codec component: snd-sc8280xp sound: ASoC: failed to instantiate card -517 genirq: Flags mismatch irq 299. 00002001 (mbhc sw intr) vs. 00002001 (mbhc sw intr) wcd938x_codec audio-codec: Failed to request mbhc interrupts -16 wcd938x_codec audio-codec: mbhc initialization failed wcd938x_codec audio-codec: ASoC: error at snd_soc_component_probe on audio-codec: -16 snd-sc8280xp sound: ASoC: failed to instantiate card -16
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: reject negative ifindexRecent changes in net-next (commit 759ab1edb56c ("net: store netdevsin an xarray")) refactored the handling of pre-assigned ifindexesand let syzbot surface a latent problem in ovs. ovs does not validateifindex, making it possible to create netdev ports with negativeifindex values. It's easy to repro with YNL:$ ./cli.py --spec netlink/specs/ovs_datapath.yaml \ --do new \ --json '{"upcall-pid": 1, "name":"my-dp"}'$ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}'$ ip link show-65536: some-port0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff...Validate the inputs. Now the second command correctly returns:$ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}'lib.ynl.NlError: Netlink error: Numerical result out of rangenl_len = 108 (92) nl_flags = 0x300 nl_type = 2 error: -34 extack: {'msg': 'integer out of range', 'unknown': [[type:4 len:36] b'\x0c\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00'], 'bad-attr': '.ifindex'}Accept 0 since it used to be silently ignored.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Don't leak a resource on swapout move errorIf moving the bo to system for swapout failed, we were leakinga resource. Fix.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on direct node in truncate_dnode()syzbot reports below bug:BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h:825 [inline] f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [inline] do_open fs/namei.c:3640 [inline] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_creat fs/open.c:1448 [inline] __se_sys_creat fs/open.c:1442 [inline] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 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 root cause is, inodeA references inodeB via inodeB's ino, once inodeAis truncated, it calls truncate_dnode() to truncate data blocks in inodeB'snode page, it traverse mapping data from node->i.i_addr[0] tonode->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.This patch fixes to add sanity check on dnode page in truncate_dnode(),so that, it can help to avoid triggering such issue, and once it encounterssuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCEerror into superblock, later fsck can detect such issue and try repairing.Also, it removes f2fs_truncate_data_blocks() for cleanup due to thefunction has only one caller, and uses f2fs_truncate_data_blocks_range()instead.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Fix uninit-value in alauda_check_media()Syzbot got KMSAN to complain about access to an uninitialized value inthe alauda subdriver of usb-storage:BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0drivers/usb/storage/alauda.c:1137CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOSGoogle 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460The problem is that alauda_check_media() doesn't verify that its USBtransfer succeeded before trying to use the received data. Whatshould happen if the transfer fails isn't entirely clear, but areasonably conservative approach is to pretend that no media ispresent.A similar problem exists in a usb_stor_dbg() call inalauda_get_media_status(). In this case, when an error occurs thecall is redundant, because usb_stor_ctrl_transfer() already will printa debugging message.Finally, unrelated to the uninitialized memory access, is the factthat alauda_check_media() performs DMA to a buffer on the stack.Fortunately usb-storage provides a general purpose DMA-able buffer foruses like this. We'll use it instead.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5-cache: fix a deadlock in r5l_exit_log()Commit b13015af94cf ("md/raid5-cache: Clear conf->log after finishingwork") introduce a new problem:// caller hold reconfig_mutexr5l_exit_log flush_work(&log->disable_writeback_work) r5c_disable_writeback_async wait_event /* * conf->log is not NULL, and mddev_trylock() * will fail, wait_event() can never pass. */ conf->log = NULLFix this problem by setting 'config->log' to NULL before wake_up() as itused to be, so that wait_event() from r5c_disable_writeback_async() canexist. In the meantime, move forward md_unregister_thread() so thatnull-ptr-deref this commit fixed can still be fixed.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dp: Drop aux devices together with DP controllerUsing devres to depopulate the aux bus made sure that upon a probedeferral the EDP panel device would be destroyed and recreated upon nextattempt.But the struct device which the devres is tied to is the DPUs(drm_dev->dev), which may be happen after the DP controller is torndown.Indications of this can be seen in the commonly seen EDID-hexdump fullof zeros in the log, or the occasional/rare KASAN fault where thepanel's attempt to read the EDID information causes a use after free onDP resources.It's tempting to move the devres to the DP controller's struct device,but the resources used by the device(s) on the aux bus are explicitlytorn down in the error path. The KASAN-reported use-after-free alsoremains, as the DP aux "module" explicitly frees its devres-allocatedmemory in this code path.As such, explicitly depopulate the aux bus in the error path, and in thecomponent unbind path, to avoid these issues.Patchwork: https://patchwork.freedesktop.org/patch/542163/
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver removeWhen the tagging protocol in current use is "ocelot-8021q" and we unbindthe driver, we see this splat:$ echo '0000:00:00.2' > /sys/bus/pci/drivers/fsl_enetc/unbindmscc_felix 0000:00:00.5 swp0: left promiscuous modesja1105 spi2.0: Link is DownDSA: tree 1 torn downmscc_felix 0000:00:00.5 swp2: left promiscuous modesja1105 spi2.2: Link is DownDSA: tree 3 torn downfsl_enetc 0000:00:00.2 eno2: left promiscuous modemscc_felix 0000:00:00.5: Link is Down------------[ cut here ]------------RTNL: assertion failed at net/dsa/tag_8021q.c (409)WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0Modules linked in:CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771pc : dsa_tag_8021q_unregister+0x12c/0x1a0lr : dsa_tag_8021q_unregister+0x12c/0x1a0Call trace: dsa_tag_8021q_unregister+0x12c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50---[ end trace 0000000000000000 ]---------------[ cut here ]------------RTNL: assertion failed at net/8021q/vlan_core.c (376)WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771pc : vlan_vid_del+0x1b8/0x1f0lr : vlan_vid_del+0x1b8/0x1f0 dsa_tag_8021q_unregister+0x8c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50DSA: tree 0 torn downThis was somewhat not so easy to spot, because "ocelot-8021q" is not thedefault tagging protocol, and thus, not everyone who tests the unbindingpath may have switched to it beforehand. The defaultfelix_tag_npi_teardown() does not require rtnl_lock() to be held.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: Call of_changeset_init() earlyWhen of_overlay_fdt_apply() fails, the changeset may be partiallyapplied, and the caller is still expected to call of_overlay_remove() toclean up this partial state.However, of_overlay_apply() calls of_resolve_phandles() beforeinit_overlay_changeset(). Hence if the overlay fails to apply due to anunresolved symbol, the overlay_changeset.cset.entries list is stilluninitialized, and cleanup will crash with a NULL-pointer dereference inoverlay_removal_is_ok().Fix this by moving the call to of_changeset_init() frominit_overlay_changeset() to of_overlay_fdt_apply(), where all otherearly initialization is done.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: bpf_sk_storage: Fix invalid wait context lockdep report'./test_progs -t test_local_storage' reported a splat:[ 27.137569] =============================[ 27.138122] [ BUG: Invalid wait context ][ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O[ 27.139542] -----------------------------[ 27.140106] test_progs/1729 is trying to lock:[ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130[ 27.141834] other info that might help us debug this:[ 27.142437] context-{5:5}[ 27.142856] 2 locks held by test_progs/1729:[ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40[ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0[ 27.145855] stack backtrace:[ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247[ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 27.149127] Call Trace:[ 27.149490] [ 27.149867] dump_stack_lvl+0x130/0x1d0[ 27.152609] dump_stack+0x14/0x20[ 27.153131] __lock_acquire+0x1657/0x2220[ 27.153677] lock_acquire+0x1b8/0x510[ 27.157908] local_lock_acquire+0x29/0x130[ 27.159048] obj_cgroup_charge+0xf4/0x3c0[ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0[ 27.161931] __kmem_cache_alloc_node+0x51/0x210[ 27.163557] __kmalloc+0xaa/0x210[ 27.164593] bpf_map_kzalloc+0xbc/0x170[ 27.165147] bpf_selem_alloc+0x130/0x510[ 27.166295] bpf_local_storage_update+0x5aa/0x8e0[ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0[ 27.169199] bpf_map_update_value+0x415/0x4f0[ 27.169871] map_update_elem+0x413/0x550[ 27.170330] __sys_bpf+0x5e9/0x640[ 27.174065] __x64_sys_bpf+0x80/0x90[ 27.174568] do_syscall_64+0x48/0xa0[ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 27.175932] RIP: 0033:0x7effb40e41ad[ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d8[ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141[ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad[ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002[ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788[ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000[ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000[ 27.184958] It complains about acquiring a local_lock while holding a raw_spin_lock.It means it should not allocate memory while holding a raw_spin_locksince it is not safe for RT.raw_spin_lock is needed because bpf_local_storage supports tracingcontext. In particular for task local storage, it is easy toget a "current" task PTR_TO_BTF_ID in tracing bpf prog.However, task (and cgroup) local storage has already been moved tobpf mem allocator which can be used after raw_spin_lock.The splat is for the sk storage. For sk (and inode) storage,it has not been moved to bpf mem allocator. Using raw_spin_lock or not,kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.However, the local storage helper requires a verifier acceptedsk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean runninga bpf prog in a kzalloc unsafe context and also able to hold a verifieraccepted sk pointer) could happen.This patch avoids kzalloc after raw_spin_lock to silent the splat.There is an existing kzalloc before the raw_spin_lock. At that point,a kzalloc is very likely required because a lookup has just been donebefore. Thus, this patch always does the kzalloc before acq---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: correct grp validation in ext4_mb_good_groupGroup corruption check will access memory of grp and will trigger kernelcrash if grp is NULL. So do NULL check before corruption check.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),overlay plane's framebuffer pointer is NULL. So, dereferencing it wouldcause a kernel Oops(NULL pointer dereferencing). Fix the issue bydisabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mm: fix VA-range sanity checkBoth create_mapping_noalloc() and update_mapping_prot() sanity-checktheir 'virt' parameter, but the check itself doesn't make much sense.The condition used today appears to be a historical accident.The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }... can only be true for the KASAN shadow region or the module region,and there's no reason to exclude these specifically for creating andupdateing mappings.When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation")... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; }At the time, VMALLOC_START was the lowest kernel address, and this waschecking whether 'virt' would be translated via TTBR1.Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }This appear to have been a thinko. The commit moved the linear map tothe bottom of the kernel address space, with VMALLOC_START being at thehalfway point. The old condition would warn for changes to the linearmap below this, and at the time VA_START was the end of the linear map.Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END")... keeping the erroneous condition as: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }Correct the condition to check against the start of the TTBR1 addressspace, which is currently PAGE_OFFSET. This simplifies the logic, andmore clearly matches the "outside kernel range" message in the warning.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ionic: remove WARN_ON to prevent panic_on_warnRemove unnecessary early code development check and the WARN_ONthat it uses. The irq alloc and free paths have long beencleaned up and this check shouldn't have stuck around so long.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/sev: Make enc_dec_hypercall() accept a size instead of npagesenc_dec_hypercall() accepted a page count instead of a size, whichforced its callers to round up. As a result, non-page alignedvaddrs caused pages to be spuriously marked as decrypted via theencryption status hypercall, which in turn caused consistentcorruption of pages during live migration. Live migration requiresaccurate encryption status information to avoid migrating pagesfrom the wrong perspective.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:thermal: of: fix double-free on unregistrationSince commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermalzone parameters structure"), thermal_zone_device_register() allocatesa copy of the tzp argument and frees it when unregistering, sothermal_of_zone_register() now ends up leaking its original tzp anddouble-freeing the tzp copy. Fix this by locating tzp on stack instead.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: TC, Fix internal port memory leakThe flow rule can be splited, and the extra post_act rules are addedto post_act table. It's possible to trigger memleak when the ruleforwards packets from internal port and over tunnel, in the case that,for example, CT 'new' state offload is allowed. As int_port object isassigned to the flow attribute of post_act rule, and its refcnt isincremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() isnot called, the refcnt is never decremented, then int_port is neverfreed.The kmemleak reports the following error:unreferenced object 0xffff888128204b80 (size 64): comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s) hex dump (first 32 bytes): 01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00 ................ 98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff .wgA.....wgA.... backtrace: [<00000000e992680d>] kmalloc_trace+0x27/0x120 [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core] [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core] [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core] [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core] [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core] [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core] [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410 [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower] [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower] [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010 [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0 [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360 [<0000000082dd6c8b>] netlink_unicast+0x438/0x710 [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50 [<0000000016e92590>] sock_sendmsg+0xc5/0x190So fix this by moving int_port cleanup code to the flow attributefree helper, which is used by all the attribute free cases.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix deadlock issue when externel_lb and reset are executed togetherWhen externel_lb and reset are executed together, a deadlock mayoccur:[ 3147.217009] INFO: task kworker/u321:0:7 blocked for more than 120 seconds.[ 3147.230483] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 3147.238999] task:kworker/u321:0 state:D stack: 0 pid: 7 ppid: 2 flags:0x00000008[ 3147.248045] Workqueue: hclge hclge_service_task [hclge][ 3147.253957] Call trace:[ 3147.257093] __switch_to+0x7c/0xbc[ 3147.261183] __schedule+0x338/0x6f0[ 3147.265357] schedule+0x50/0xe0[ 3147.269185] schedule_preempt_disabled+0x18/0x24[ 3147.274488] __mutex_lock.constprop.0+0x1d4/0x5dc[ 3147.279880] __mutex_lock_slowpath+0x1c/0x30[ 3147.284839] mutex_lock+0x50/0x60[ 3147.288841] rtnl_lock+0x20/0x2c[ 3147.292759] hclge_reset_prepare+0x68/0x90 [hclge][ 3147.298239] hclge_reset_subtask+0x88/0xe0 [hclge][ 3147.303718] hclge_reset_service_task+0x84/0x120 [hclge][ 3147.309718] hclge_service_task+0x2c/0x70 [hclge][ 3147.315109] process_one_work+0x1d0/0x490[ 3147.319805] worker_thread+0x158/0x3d0[ 3147.324240] kthread+0x108/0x13c[ 3147.328154] ret_from_fork+0x10/0x18In externel_lb process, the hns3 driver call napi_disable()first, then the reset happen, then the restore process of theexternel_lb will fail, and will not call napi_enable(). Whendoing externel_lb again, napi_disable() will be double call,cause a deadlock of rtnl_lock().This patch use the HNS3_NIC_STATE_DOWN state to protect thecalling of napi_disable() and napi_enable() in externel_lbprocess, just as the usage in ndo_stop() and ndo_start().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: r8712: Fix memory leak in _r8712_init_xmit_priv()In the above mentioned routine, memory is allocated in several places.If the first succeeds and a later one fails, the routine will leak memory.This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driverto the mainline kernel"). A potential memory leak inr8712_xmit_resource_alloc() is also addressed.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix memory leak in binder_init()In binder_init(), the destruction of binder_alloc_shrinker_init() is notperformed in the wrong path, which will cause memory leaks. So this commitintroduces binder_alloc_shrinker_exit() and calls it in the wrong path tofix that.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-race around unix_tot_inflight.unix_tot_inflight is changed under spin_lock(unix_gc_lock), butunix_release_sock() reads it locklessly.Let's use READ_ONCE() for unix_tot_inflight.Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:annote lockless accesses to unix_tot_inflight & gc_in_progress")BUG: KCSAN: data-race in unix_inflight / unix_release_sockwrite (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1: unix_inflight+0x130/0x180 net/unix/scm.c:64 unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1832 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x148/0x160 net/socket.c:747 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493 ___sys_sendmsg+0xc6/0x140 net/socket.c:2547 __sys_sendmsg+0x94/0x140 net/socket.c:2576 __do_sys_sendmsg net/socket.c:2585 [inline] __se_sys_sendmsg net/socket.c:2583 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583 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 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0: unix_release_sock+0x608/0x910 net/unix/af_unix.c:671 unix_release+0x59/0x80 net/unix/af_unix.c:1058 __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1385 __fput+0x179/0x5e0 fs/file_table.c:321 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0x00000000 -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:virtio_vdpa: build affinity masks conditionallyWe try to build affinity mask via create_affinity_masks()unconditionally which may lead several issues:- the affinity mask is not used for parent without affinity support (only VDUSE support the affinity now)- the logic of create_affinity_masks() might not work for devices other than block. For example it's not rare in the networking device where the number of queues could exceed the number of CPUs. Such case breaks the current affinity logic which is based on group_cpus_evenly() who assumes the number of CPUs are not less than the number of groups. This can trigger a warning[1]: if (ret >= 0) WARN_ON(nr_present + nr_others < numgrps);Fixing this by only build the affinity masks only when- Driver passes affinity descriptor, driver like virtio-blk can make sure to limit the number of queues when it exceeds the number of CPUs- Parent support affinity setting config opsThis help to avoid the warning. More optimizations could be done ontop.[1][ 682.146655] WARNING: CPU: 6 PID: 1550 at lib/group_cpus.c:400 group_cpus_evenly+0x1aa/0x1c0[ 682.146668] CPU: 6 PID: 1550 Comm: vdpa Not tainted 6.5.0-rc5jason+ #79[ 682.146671] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014[ 682.146673] RIP: 0010:group_cpus_evenly+0x1aa/0x1c0[ 682.146676] Code: 4c 89 e0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc e8 1b c4 74 ff 48 89 ef e8 13 ac 98 ff 4c 89 e7 45 31 e4 e8 08 ac 98 ff eb c2 <0f> 0b eb b6 e8 fd 05 c3 00 45 31 e4 eb e5 cc cc cc cc cc cc cc cc[ 682.146679] RSP: 0018:ffffc9000215f498 EFLAGS: 00010293[ 682.146682] RAX: 000000000001f1e0 RBX: 0000000000000041 RCX: 0000000000000000[ 682.146684] RDX: ffff888109922058 RSI: 0000000000000041 RDI: 0000000000000030[ 682.146686] RBP: ffff888109922058 R08: ffffc9000215f498 R09: ffffc9000215f4a0[ 682.146687] R10: 00000000000198d0 R11: 0000000000000030 R12: ffff888107e02800[ 682.146689] R13: 0000000000000030 R14: 0000000000000030 R15: 0000000000000041[ 682.146692] FS: 00007fef52315740(0000) GS:ffff888237380000(0000) knlGS:0000000000000000[ 682.146695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 682.146696] CR2: 00007fef52509000 CR3: 0000000110dbc004 CR4: 0000000000370ee0[ 682.146698] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 682.146700] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 682.146701] Call Trace:[ 682.146703] [ 682.146705] ? __warn+0x7b/0x130[ 682.146709] ? group_cpus_evenly+0x1aa/0x1c0[ 682.146712] ? report_bug+0x1c8/0x1e0[ 682.146717] ? handle_bug+0x3c/0x70[ 682.146721] ? exc_invalid_op+0x14/0x70[ 682.146723] ? asm_exc_invalid_op+0x16/0x20[ 682.146727] ? group_cpus_evenly+0x1aa/0x1c0[ 682.146729] ? group_cpus_evenly+0x15c/0x1c0[ 682.146731] create_affinity_masks+0xaf/0x1a0[ 682.146735] virtio_vdpa_find_vqs+0x83/0x1d0[ 682.146738] ? __pfx_default_calc_sets+0x10/0x10[ 682.146742] virtnet_find_vqs+0x1f0/0x370[ 682.146747] virtnet_probe+0x501/0xcd0[ 682.146749] ? vp_modern_get_status+0x12/0x20[ 682.146751] ? get_cap_addr.isra.0+0x10/0xc0[ 682.146754] virtio_dev_probe+0x1af/0x260[ 682.146759] really_probe+0x1a5/0x410
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()Klocwork reported warning of rport maybe NULL and will be dereferenced.rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.Check valid rport returned by fc_bsg_to_rport().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:sched/psi: use kernfs polling functions for PSI trigger pollingDestroying psi trigger in cgroup_file_release causes UAF issues whena cgroup is removed from under a polling process. This is happeningbecause cgroup removal causes a call to cgroup_file_release while theactual file is still alive. Destroying the trigger at this point wouldalso destroy its waitqueue head and if there is still a polling processon that file accessing the waitqueue, it will step on the freed pointer:do_select vfs_poll do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy wake_up_pollfree(&t->event_wait)// vfs_poll is unblocked synchronize_rcu kfree(t) poll_freewait -> UAF access to the trigger's waitqueue headPatch [1] fixed this issue for epoll() case using wake_up_pollfree(),however the same issue exists for synchronous poll() case.The root cause of this issue is that the lifecycles of the psi trigger'swaitqueue and of the file associated with the trigger are different. Fixthis by using kernfs_generic_poll function when polling on cgroup-specificpsi triggers. It internally uses kernfs_open_node->poll waitqueue headwith its lifecycle tied to the file's lifecycle. This also renders thefix in [1] obsolete, so revert it.[1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential memory leaks at error path for UMP openThe allocation and initialization errors at alloc_midi_urbs() that iscalled at MIDI 2.0 / UMP device are supposed to be handled at thecaller side by invoking free_midi_urbs(). However, free_midi_urbs()loops only for ep->num_urbs entries, and since ep->num_entries wasn'tupdated yet at the allocation / init error in alloc_midi_urbs(), thisentry won't be released.The intention of free_midi_urbs() is to release the whole elements, sochange the loop size to NUM_URBS to scan over all elements for fixingthe missed releases.Also, the call of free_midi_urbs() is missing atsnd_usb_midi_v2_open(). Although it'll be released later atreopen/close or disconnection, it's better to release immediately atthe error path.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rsi: Do not configure WoWlan in shutdown hook if not enabledIn case WoWlan was never configured during the operation of the system,the hw->wiphy->wowlan_config will be NULL. rsi_config_wowlan() checkswhether wowlan_config is non-NULL and if it is not, then WARNs about it.The warning is valid, as during normal operation the rsi_config_wowlan()should only ever be called with non-NULL wowlan_config. In shutdown thisrsi_config_wowlan() should only ever be called if WoWlan was configuredbefore by the user.Add checks for non-NULL wowlan_config into the shutdown hook. While at it,check whether the wiphy is also non-NULL before accessing wowlan_config .Drop the single-use wowlan_config variable, just inline it into functioncall.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:opp: Fix use-after-free in lazy_opp_tables after probe deferralWhen dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns-EPROBE_DEFER, the opp_table is freed again, to wait until all theinterconnect paths are available.However, if the OPP table is using required-opps then it may alreadyhave been added to the global lazy_opp_tables list. The error pathdoes not remove the opp_table from the list again.This can cause crashes later when the provider of the required-oppsis added, since we will iterate over OPP tables that have already beenfreed. E.g.: Unable to handle kernel NULL pointer dereference when read CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3 PC is at _of_add_opp_table_v2 (include/linux/of.h:949 drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404 drivers/opp/of.c:1032) -> lazy_link_required_opp_table()Fix this by calling _of_clear_opp_table() to remove the opp_table fromthe list and clear other allocated resources. While at it, also add themissing mutex_destroy() calls in the error path.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iio: core: Prevent invalid memory access when there is no parentCommit 813665564b3d ("iio: core: Convert to use firmware node handleinstead of OF node") switched the kind of nodes to use for labelretrieval in device registration. Probably an unwanted change in thatcommit was that if the device has no parent then NULL pointer isaccessed. This is what happens in the stock IIO dummy driver when anew entry is created in configfs: # mkdir /sys/kernel/config/iio/devices/dummy/foo BUG: kernel NULL pointer dereference, address: ... ... Call Trace: __iio_device_register iio_dummy_probeSince there seems to be no reason to make a parent device of an IIOdummy device mandatory, let's prevent the invalid memory access in__iio_device_register when the parent device is NULL. With thischange, the IIO dummy driver works fine with configfs.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add queue index attr to vdpa_nl_policy for nlattr length checkThe vdpa_nl_policy structure is used to validate the nlattr when parsingthe incoming nlmsg. It will ensure the attribute being described producesa valid nlattr pointer in info->attrs before entering into each handlerin vdpa_nl_ops.That is to say, the missing part in vdpa_nl_policy may lead to illegalnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.This patch adds the missing nla_policy for vdpa queue index attr to avoidsuch bugs.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix underflow in chain reference counterSet element addition error path decrements reference counter on chainstwice: once on element release and again via nft_data_release().Then, d6b478666ffa ("netfilter: nf_tables: fix underflow in objectreference counter") incorrectly fixed this by removing the statefulobject reference count decrement.Restore the stateful object decrement as in b91d90368837 ("netfilter:nf_tables: fix leaking object reference count") and letnft_data_release() decrement the chain reference counter, so this isdone only once.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no linkhci_connect_sco currently returns NULL when there is no link (i.e. whenhci_conn_link() returns NULL).sco_connect() expects an ERR_PTR in case of any error (see line 266 insco.c). Thus, hcon set as NULL passes through to sco_conn_add(), whichtries to get hcon->hdev, resulting in dereferencing a NULL pointer asreported by syzkaller.The same issue exists for iso_connect_cis() calling hci_connect_cis().Thus, make hci_connect_sco() and hci_connect_cis() return ERR_PTRinstead of NULL.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:audit: fix possible soft lockup in __audit_inode_child()Tracefs or debugfs maybe cause hundreds to thousands of PATH records,too many PATH records maybe cause soft lockup.For example: 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4. mkdir /sys/kernel/debug/tracing/instances/testThere may be a soft lockup as follows: watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498] Kernel panic - not syncing: softlockup: hung tasks Call trace: dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340 __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140 __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180Therefore, we add cond_resched() to __audit_inode_child() to fix it.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:rpmsg: glink: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: fix skb leak by txs missing in AMSDUtxs may be dropped if the frame is aggregated in AMSDU. When the problemshows up, some SKBs would be hold in driver to cause network stoppedtemporarily. Even if the problem can be recovered by txs timeout handling,mt7921 still need to disable txs in AMSDU to avoid this issue.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi:ssif: Fix a memory leak when scanning for an adapterThe adapter scan ssif_info_find() sets info->adapter_name if the adapterinfo came from SMBIOS, as it's not set in that case. However, thisfunction can be called more than once, and it will leak the adapter nameif it had already been set. So check for NULL before setting it.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xferIn gl861_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 gl861_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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix BUG in ext4_mb_new_inode_pa() due to overflowWhen we calculate the end position of ext4_free_extent, this position maybe exactly where ext4_lblk_t (i.e. uint) overflows. For example, ifac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then thecomputed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is notthe first case of adjusting the best extent, that is, new_bex_end > 0, thefollowing BUG_ON will be triggered:=========================================================kernel BUG at fs/ext4/mballoc.c:5116!invalid opcode: 0000 [#1] PREEMPT SMP PTICPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430Call Trace: ext4_mb_use_best_found+0x203/0x2f0 ext4_mb_try_best_found+0x163/0x240 ext4_mb_regular_allocator+0x158/0x1550 ext4_mb_new_blocks+0x86a/0xe10 ext4_ext_map_blocks+0xb0c/0x13a0 ext4_map_blocks+0x2cd/0x8f0 ext4_iomap_begin+0x27b/0x400 iomap_iter+0x222/0x3d0 __iomap_dio_rw+0x243/0xcb0 iomap_dio_rw+0x16/0x80=========================================================A simple reproducer demonstrating the problem: mkfs.ext4 -F /dev/sda -b 4096 100M mount /dev/sda /tmp/test fallocate -l1M /tmp/test/tmp fallocate -l10M /tmp/test/file fallocate -i -o 1M -l16777203M /tmp/test/file fsstress -d /tmp/test -l 0 -n 100000 -p 8 & sleep 10 && killall -9 fsstress rm -f /tmp/test/tmp xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"We simply refactor the logic for adjusting the best extent by addinga temporary ext4_free_extent ex and use extent_logical_end() to avoidoverflow, which also simplifies the code.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:igb: clean up in all error paths when enabling SR-IOVAfter commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removingthe igb module could hang or crash (depending on the machine) when themodule has been loaded with the max_vfs parameter set to some value != 0.In case of one test machine with a dual port 82580, this hang occurred:[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1[ 233.093257] igb 0000:41:00.1: IOV Disabled[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback)[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed[ 234.157244] igb 0000:41:00.0: IOV Disabled[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.[ 371.627489] Not tainted 6.4.0-dirty #2[ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this.[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0[ 371.650330] Call Trace:[ 371.653061] [ 371.655407] __schedule+0x20e/0x660[ 371.659313] schedule+0x5a/0xd0[ 371.662824] schedule_preempt_disabled+0x11/0x20[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10[ 371.678105] report_error_detected+0x25/0x1c0[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10[ 371.688618] pci_walk_bus+0x72/0x90[ 371.692519] pcie_do_recovery+0xb2/0x330[ 371.696899] aer_process_err_devices+0x117/0x170[ 371.702055] aer_isr+0x1c0/0x1e0[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10[ 371.715496] irq_thread_fn+0x20/0x60[ 371.719491] irq_thread+0xe6/0x1b0[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10[ 371.728255] ? __pfx_irq_thread+0x10/0x10[ 371.732731] kthread+0xe2/0x110[ 371.736243] ? __pfx_kthread+0x10/0x10[ 371.740430] ret_from_fork+0x2c/0x50[ 371.744428] The reproducer was a simple script: #!/bin/sh for i in `seq 1 5`; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb doneIt turned out that this could only be reproduce on 82580 (quad anddual-port), but not on 82576, i350 and i210. Further debugging showedthat igb_enable_sriov()'s call to pci_enable_sriov() is failing, becausedev->is_physfn is 0 on 82580.Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),igb_enable_sriov() jumped into the "err_out" cleanup branch. After thiscommit it only returned the error code.So the cleanup didn't take place, and the incorrect VF setup in theigb_adapter structure fooled the igb driver into assuming that VFs havebeen set up where no VF actually existed.Fix this problem by cleaning up again if pci_enable_sriov() fails.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: hold queue_lock when removing blkg->q_nodeWhen blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lockhas to be held, otherwise, all kinds of bugs(list corruption, hard lockup,..) can be triggered from blkg_destroy_all().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: s390: pv: fix index value of replaced ASCEThe index field of the struct page corresponding to a guest ASCE shouldbe 0. When replacing the ASCE in s390_replace_asce(), the index of thenew ASCE should also be set to 0.Having the wrong index might lead to the wrong addresses being passedaround when notifying pte invalidations, and eventually to validityintercepts (VM crash) if the prefix gets unmapped and the notifier getscalled with the wrong address.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: anysee: fix null-ptr-deref in anysee_master_xferIn anysee_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 anysee_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()")[hverkuil: add spaces around +]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/iommu: Fix notifiers being shared by PCI and VIO busesfail_iommu_setup() registers the fail_iommu_bus_notifier struct to bothPCI and VIO buses. struct notifier_block is a linked list node, so thiscauses any notifiers later registered to either bus type to also beregistered to the other since they share the same node.This causes issues in (at least) the vgaarb code, which registers anotifier for PCI buses. pci_notify() ends up being called on a viodevice, converted with to_pci_dev() even though it's not a PCI device,and finally makes a bad access in vga_arbiter_add_pci_device() asdiscovered with KASAN: BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00 Read of size 4 at addr c000000264c26fdc by task swapper/0/1 Call Trace: dump_stack_lvl+0x1bc/0x2b8 (unreliable) print_report+0x3f4/0xc60 kasan_report+0x244/0x698 __asan_load4+0xe8/0x250 vga_arbiter_add_pci_device+0x60/0xe00 pci_notify+0x88/0x444 notifier_call_chain+0x104/0x320 blocking_notifier_call_chain+0xa0/0x140 device_add+0xac8/0x1d30 device_register+0x58/0x80 vio_register_device_node+0x9ac/0xce0 vio_bus_scan_register_devices+0xc4/0x13c __machine_initcall_pseries_vio_device_init+0x94/0xf0 do_one_initcall+0x12c/0xaa8 kernel_init_freeable+0xa48/0xba8 kernel_init+0x64/0x400 ret_from_kernel_thread+0x5c/0x64Fix this by creating separate notifier_block structs for each bus type.[mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Protect reconfiguration of sb read-write from racing writesThe reconfigure / remount code takes a lot of effort to protectfilesystem's reconfiguration code from racing writes on remountingread-only. However during remounting read-only filesystem to read-writemode userspace writes can start immediately once we clear SB_RDONLYflag. This is inconvenient for example for ext4 because we need to dosome writes to the filesystem (such as preparation of quota files)before we can take userspace writes so we are clearing SB_RDONLY flagbefore we are fully ready to accept userpace writes and syzbot has founda way to exploit this [1]. Also as far as I'm reading the codethe filesystem remount code was protected from racing writes in thelegacy mount path by the mount's MNT_READONLY flag so this is relativelynew problem. It is actually fairly easy to protect remount read-writefrom racing writes using sb->s_readonly_remount flag so let's just dothat instead of having to workaround these races in the filesystem code.[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fix potential memory leak in mlx5e_init_rep_rxThe memory pointed to by the priv->rx_res pointer is not freed in the errorpath of mlx5e_init_rep_rx, which can lead to a memory leak. Fix by freeingthe memory in the error path, thereby making the error path identical tomlx5e_cleanup_rep_rx().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:rcu: dump vmalloc memory info safelyCurrently, for double invoke call_rcu(), will dump rcu_head objects memoryinfo, if the objects is not allocated from the slab allocator, thevmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need tobe held, since the call_rcu() can be invoked in interrupt context,therefore, there is a possibility of spinlock deadlock scenarios.And in Preempt-RT kernel, the rcutorture test also trigger the followinglockdep warning:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 1, expected: 0RCU nest depth: 1, expected: 13 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70irq event stamp: 565512hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0Preemption disabled at:[] rcu_torture_init+0x1f13/0x2370CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 The previous patch fixes this by using the deadlock-safe best-effortversion of find_vm_area. However, in case of failure print the fact thatthe pointer was a vmalloc pointer so that we print at least something.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/dcssblk: fix kernel crash with list_add corruptionCommit fb08a1908cb1 ("dax: simplify the dax_device <-> gendiskassociation") introduced new logic for gendisk association, requiringdrivers to explicitly call dax_add_host() and dax_remove_host().For dcssblk driver, some dax_remove_host() calls were missing, e.g. indevice remove path. The commit also broke error handling for out_dax casein device add path, resulting in an extra put_device() w/o the previousget_device() in that case.This lead to stale xarray entries after device add / remove cycles. In thecase when a previously used struct gendisk pointer (xarray index) would beused again, because blk_alloc_disk() happened to return such a pointer, thexa_insert() in dax_add_host() would fail and go to out_dax, doing the extraput_device() in the error path. In combination with an already flawed errorhandling in dcssblk (device_register() cleanup), which needs to beaddressed in a separate patch, this resulted in a missing device_del() /klist_del(), and eventually in the kernel crash with list_add corruption ona subsequent device_add() / klist_add().Fix this by adding the missing dax_remove_host() calls, and also move theput_device() in the error path to restore the previous logic.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Add missing hw_ops->get_ring_selector() for IPQ5018During sending data after clients connected, hw_ops->get_ring_selector()will be called. But for IPQ5018, this member isn't set, and thefollowing NULL pointer exception will be occurred: [ 38.840478] 8<--- cut here --- [ 38.840517] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [ 38.923161] PC is at 0x0 [ 38.927930] LR is at ath11k_dp_tx+0x70/0x730 [ath11k] ... [ 39.063264] Process hostapd (pid: 1034, stack limit = 0x801ceb3d) [ 39.068994] Stack: (0x856a9a68 to 0x856aa000) ... [ 39.438467] [<7f323804>] (ath11k_dp_tx [ath11k]) from [<7f314e6c>] (ath11k_mac_op_tx+0x80/0x190 [ath11k]) [ 39.446607] [<7f314e6c>] (ath11k_mac_op_tx [ath11k]) from [<7f17dbe0>] (ieee80211_handle_wake_tx_queue+0x7c/0xc0 [mac80211]) [ 39.456162] [<7f17dbe0>] (ieee80211_handle_wake_tx_queue [mac80211]) from [<7f174450>] (ieee80211_probereq_get+0x584/0x704 [mac80211]) [ 39.467443] [<7f174450>] (ieee80211_probereq_get [mac80211]) from [<7f178c40>] (ieee80211_tx_prepare_skb+0x1f8/0x248 [mac80211]) [ 39.479334] [<7f178c40>] (ieee80211_tx_prepare_skb [mac80211]) from [<7f179e28>] (__ieee80211_subif_start_xmit+0x32c/0x3d4 [mac80211]) [ 39.491053] [<7f179e28>] (__ieee80211_subif_start_xmit [mac80211]) from [<7f17af08>] (ieee80211_tx_control_port+0x19c/0x288 [mac80211]) [ 39.502946] [<7f17af08>] (ieee80211_tx_control_port [mac80211]) from [<7f0fc704>] (nl80211_tx_control_port+0x174/0x1d4 [cfg80211]) [ 39.515017] [<7f0fc704>] (nl80211_tx_control_port [cfg80211]) from [<808ceac4>] (genl_rcv_msg+0x154/0x340) [ 39.526814] [<808ceac4>] (genl_rcv_msg) from [<808cdb74>] (netlink_rcv_skb+0xb8/0x11c) [ 39.536446] [<808cdb74>] (netlink_rcv_skb) from [<808ce1d0>] (genl_rcv+0x28/0x34) [ 39.544344] [<808ce1d0>] (genl_rcv) from [<808cd234>] (netlink_unicast+0x174/0x274) [ 39.551895] [<808cd234>] (netlink_unicast) from [<808cd510>] (netlink_sendmsg+0x1dc/0x440) [ 39.559362] [<808cd510>] (netlink_sendmsg) from [<808596e0>] (____sys_sendmsg+0x1a8/0x1fc) [ 39.567697] [<808596e0>] (____sys_sendmsg) from [<8085b1a8>] (___sys_sendmsg+0xa4/0xdc) [ 39.575941] [<8085b1a8>] (___sys_sendmsg) from [<8085b310>] (sys_sendmsg+0x44/0x74) [ 39.583841] [<8085b310>] (sys_sendmsg) from [<80300060>] (ret_fast_syscall+0x0/0x40) ... [ 39.620734] Code: bad PC value [ 39.625869] ---[ end trace 8aef983ad3cbc032 ]---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: turn quotas off if mount failed after enabling quotasYi found during a review of the patch "ext4: don't BUG on inconsistentjournal feature" that when ext4_mark_recovery_complete() returns an errorvalue, the error handling path does not turn off the enabled quotas,which triggers the following kmemleak:================================================================unreferenced object 0xffff8cf68678e7c0 (size 64):comm "mount", pid 746, jiffies 4294871231 (age 11.540s)hex dump (first 32 bytes):00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A...c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H...backtrace:[<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880[<00000000d4e621d7>] kmalloc_trace+0x39/0x140[<00000000837eee74>] v2_read_file_info+0x18a/0x3a0[<0000000088f6c877>] dquot_load_quota_sb+0x2ed/0x770[<00000000340a4782>] dquot_load_quota_inode+0xc6/0x1c0[<0000000089a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4][<000000003a0268fa>] __ext4_fill_super+0x3448/0x3910 [ext4][<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4][<000000004a9489c4>] get_tree_bdev+0x1dc/0x370[<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4][<00000000c7cb663d>] vfs_get_tree+0x31/0x160[<00000000320e1bed>] do_new_mount+0x1d5/0x480[<00000000c074654c>] path_mount+0x22e/0xbe0[<0000000003e97a8e>] do_mount+0x95/0xc0[<000000002f3d3736>] __x64_sys_mount+0xc4/0x160[<0000000027d2140c>] do_syscall_64+0x3f/0x90================================================================To solve this problem, we add a "failed_mount10" tag, and callext4_quota_off_umount() in this tag to release the enabled qoutas.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix crash when reading stats while NIC is resettingefx_net_stats() (.ndo_get_stats64) can be called during an ethtool selftest, during which time nic_data->mc_stats is NULL as the NIC has been fini'd. In this case do not attempt to fetch the latest stats from the hardware, else we will crash on a NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000038 RIP efx_nic_update_stats abridged calltrace: efx_ef10_update_stats_pf efx_net_stats dev_get_stats dev_seq_printf_statsSkipping the read is safe, we will simply give out stale stats.To ensure that the free in efx_ef10_fini_nic() does not race against efx_ef10_update_stats_pf(), which could cause a TOCTTOU bug, take the efx->stats_lock in fini_nic (it is already held across update_stats).
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: ISO: fix iso_conn related locking and validity issuessk->sk_state indicates whether iso_pi(sk)->conn is valid. Operationsthat check/update sk_state and access conn should hold lock_sock,otherwise they can race.The order of taking locks is hci_dev_lock > lock_sock > iso_conn_lock,which is how it is in connect/disconnect_cfm -> iso_conn_del ->iso_chan_del.Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sockaround updating sk_state and conn.iso_conn_del must not occur during iso_connect_cis/bis, as it frees theiso_conn. Hold hdev->lock longer to prevent that.This should not reintroduce the issue fixed in commit 241f51931c35("Bluetooth: ISO: Avoid circular locking dependency"), since the weacquire locks in order. We retain the fix in iso_sock_connect to releaselock_sock before iso_connect_* acquires hdev->lock.Similarly for commit 6a5ad251b7cd ("Bluetooth: ISO: Fix possiblecircular locking dependency"). We retain the fix in iso_conn_ready tonot acquire iso_conn_lock before lock_sock.iso_conn_add shall return iso_conn with valid hcon. Make it so also whenreusing an old CIS connection waiting for disconnect timeout (see__iso_sock_close where conn->hcon is set to NULL).Trace with iso_conn_del after iso_chan_add in iso_connect_cis:===============================================================iso_sock_create:771: sock 00000000be9b69b7iso_sock_init:693: sk 000000004dff667eiso_sock_bind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1iso_sock_setsockopt:1289: sk 000000004dff667eiso_sock_setsockopt:1289: sk 000000004dff667eiso_sock_setsockopt:1289: sk 000000004dff667eiso_sock_connect:875: sk 000000004dff667eiso_connect_cis:353: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:dahci_get_route:1199: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:dahci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:daiso_conn_add:140: hcon 000000007b65d182 conn 00000000daf8625e__iso_chan_add:214: conn 00000000daf8625eiso_connect_cfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12iso_conn_del:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16iso_sock_clear_timer:117: sock 000000004dff667e state 3 iso_chan_del:153: sk 000000004dff667e, conn 00000000daf8625e, err 16hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535hci_conn_unlink:1102: hci0: hcon 000000007b65d182hci_chan_list_flush:2780: hcon 000000007b65d182iso_sock_getsockopt:1376: sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_getsockopt:1376: sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_shutdown:1434: sock 00000000be9b69b7, sk 000000004dff667e, how 1__iso_sock_close:632: sk 000000004dff667e state 5 socket 00000000be9b69b7 BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0Oops: 0000 [#1] PREEMPT SMP PTIHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014RIP: 0010:__iso_sock_close (net/bluetooth/iso.c:664) bluetooth===============================================================Trace with iso_conn_del before iso_chan_add in iso_connect_cis:===============================================================iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da...iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504hci_dev_put:1487: hci0 orig refcnt 21hci_event_packet:7607: hci0: e---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:keys: Fix linking a duplicate key to a keyring's assoc_arrayWhen making a DNS query inside the kernel using dns_query(), the requestcode can in rare cases end up creating a duplicate index key in theassoc_array of the destination keyring. It is eventually found bya BUG_ON() check in the assoc_array implementation and results ina crash.Example report:[2158499.700025] kernel BUG at ../lib/assoc_array.c:652![2158499.700039] invalid opcode: 0000 [#1] SMP PTI[2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3[2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020[2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs][2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40[2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff <0f> 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f[2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282[2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005[2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000[2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000[2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28[2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740[2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000[2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0[2158499.700702] Call Trace:[2158499.700741] ? key_alloc+0x447/0x4b0[2158499.700768] ? __key_link_begin+0x43/0xa0[2158499.700790] __key_link_begin+0x43/0xa0[2158499.700814] request_key_and_link+0x2c7/0x730[2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver][2158499.700873] ? key_default_cmp+0x20/0x20[2158499.700898] request_key_tag+0x43/0xa0[2158499.700926] dns_query+0x114/0x2ca [dns_resolver][2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs][2158499.701164] ? scnprintf+0x49/0x90[2158499.701190] ? __switch_to_asm+0x40/0x70[2158499.701211] ? __switch_to_asm+0x34/0x70[2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs][2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs][2158499.701632] process_one_work+0x1f8/0x3e0[2158499.701658] worker_thread+0x2d/0x3f0[2158499.701682] ? process_one_work+0x3e0/0x3e0[2158499.701703] kthread+0x10d/0x130[2158499.701723] ? kthread_park+0xb0/0xb0[2158499.701746] ret_from_fork+0x1f/0x40The situation occurs as follows:* Some kernel facility invokes dns_query() to resolve a hostname, for example, "abcdef". The function registers its global DNS resolver cache as current->cred.thread_keyring and passes the query to request_key_net() -> request_key_tag() -> request_key_and_link().* Function request_key_and_link() creates a keyring_search_context object. Its match_data.cmp method gets set via a call to type->match_preparse() (resolves to dns_resolver_match_preparse()) to dns_resolver_cmp().* Function request_key_and_link() continues and invokes search_process_keyrings_rcu() which returns that a given key was not found. The control is then passed to request_key_and_link() -> construct_alloc_key().* Concurrently to that, a second task similarly makes a DNS query for "abcdef." and its result gets inserted into the DNS resolver cache.* Back on the first task, function construct_alloc_key() first runs __key_link_begin() to determine an assoc_array_edit operation to insert a new key. Index keys in the array are compared exactly as-is, using keyring_compare_object(). The operation ---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/hyperv: Disable IBT when hypercall page lacks ENDBR instructionOn hardware that supports Indirect Branch Tracking (IBT), Hyper-V VMswith ConfigVersion 9.3 or later support IBT in the guest. However,current versions of Hyper-V have a bug in that there's not an ENDBR64instruction at the beginning of the hypercall page. Since hypercalls aremade with an indirect call to the hypercall page, all hypercall attemptsfail with an exception and Linux panics.A Hyper-V fix is in progress to add ENDBR64. But guard against the Linuxpanic by clearing X86_FEATURE_IBT if the hypercall page doesn't startwith ENDBR. The VM will boot and run without IBT.If future Linux 32-bit kernels were to support IBT, additional hypercallpage hackery would be needed to make IBT work for such kernels in aHyper-V VM.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Disable preemption in bpf_event_outputWe received report [1] of kernel crash, which is caused byusing nesting protection without disabled preemption.The bpf_event_output can be called by programs executed bybpf_prog_run_array_cg function that disabled migration butkeeps preemption enabled.This can cause task to be preempted by another one inside thenesting protection and lead eventually to two tasks using sameperf_sample_data buffer and cause crashes like: BUG: kernel NULL pointer dereference, address: 0000000000000001 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page ... ? perf_output_sample+0x12a/0x9a0 ? finish_task_switch.isra.0+0x81/0x280 ? perf_event_output+0x66/0xa0 ? bpf_event_output+0x13a/0x190 ? bpf_event_output_data+0x22/0x40 ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb ? xa_load+0x87/0xe0 ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0 ? release_sock+0x3e/0x90 ? sk_setsockopt+0x1a1/0x12f0 ? udp_pre_connect+0x36/0x50 ? inet_dgram_connect+0x93/0xa0 ? __sys_connect+0xb4/0xe0 ? udp_setsockopt+0x27/0x40 ? __pfx_udp_push_pending_frames+0x10/0x10 ? __sys_setsockopt+0xdf/0x1a0 ? __x64_sys_connect+0xf/0x20 ? do_syscall_64+0x3a/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdcFixing this by disabling preemption in bpf_event_output.[1] https://github.com/cilium/cilium/issues/26756
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()when kmalloc() fail to allocate memory in kasprintf(), nameor full_name will be NULL, strcmp() will causenull pointer dereference.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix issue in verifying allow_ptr_leaksAfter we converted the capabilities of our networking-bpf program fromcap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf programfailed to start. Because it failed the bpf verifier, and the error logis "R3 pointer comparison prohibited".A simple reproducer as follows,SEC("cls-ingress")int ingress(struct __sk_buff *skb){ struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK;}Per discussion with Yonghong and Alexei [1], comparison of two packetpointers is not a pointer leak. This patch fixes it.Our local kernel is 6.1.y and we expect this fix to be backported to6.1.y, so stable is CCed.[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pstore/ram: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sunplus: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value,1. the memory allocated in mmc_alloc_host() will be leaked2. null-ptr-deref will happen when calling mmc_remove_host()in remove function spmmc_drv_remove() because deleting notadded device.Fix this by checking the return value of mmc_add_host(). Moreover,I fixed the error handling path of spmmc_drv_probe() to clean up.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix warning in trace_buffered_event_disable()Warning happened in trace_buffered_event_disable() at WARN_ON_ONCE(!trace_buffered_event_ref) Call Trace: ? __warn+0xa5/0x1b0 ? trace_buffered_event_disable+0x189/0x1b0 __ftrace_event_enable_disable+0x19e/0x3e0 free_probe_data+0x3b/0xa0 unregister_ftrace_function_probe_func+0x6b8/0x800 event_enable_func+0x2f0/0x3d0 ftrace_process_regex.isra.0+0x12d/0x1b0 ftrace_filter_write+0xe6/0x140 vfs_write+0x1c9/0x6f0 [...]The cause of the warning is in __ftrace_event_enable_disable(),trace_buffered_event_enable() was called once whiletrace_buffered_event_disable() was called twice.Reproduction script show as below, for analysis, see the comments: ``` #!/bin/bash cd /sys/kernel/tracing/ # 1. Register a 'disable_event' command, then: # 1) SOFT_DISABLED_BIT was set; # 2) trace_buffered_event_enable() was called first time; echo 'cmdline_proc_show:disable_event:initcall:initcall_finish' > \ set_ftrace_filter # 2. Enable the event registered, then: # 1) SOFT_DISABLED_BIT was cleared; # 2) trace_buffered_event_disable() was called first time; echo 1 > events/initcall/initcall_finish/enable # 3. Try to call into cmdline_proc_show(), then SOFT_DISABLED_BIT was # set again!!! cat /proc/cmdline # 4. Unregister the 'disable_event' command, then: # 1) SOFT_DISABLED_BIT was cleared again; # 2) trace_buffered_event_disable() was called second time!!! echo '!cmdline_proc_show:disable_event:initcall:initcall_finish' > \ set_ftrace_filter ```To fix it, IIUC, we can change to call trace_buffered_event_enable() atfist time soft-mode enabled, and call trace_buffered_event_disable() atlast time soft-mode disabled.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Fix oops for port->pm on uart_change_pm()Unloading a hardware specific 8250 driver can produce error "Unable tohandle kernel paging request at virtual address" about ten seconds afterunloading the driver. This happens on uart_hangup() callinguart_change_pm().Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on portspecific driver unbind") was only a partial fix. If the hardware specificdriver has initialized port->pm function, we need to clear port->pm too.Just reinitializing port->ops does not do this. Otherwise serial8250_pm()will call port->pm() instead of serial8250_do_pm().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()rule_locs is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrule_locs to avoid NULL pointer dereference.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX.syzkaller found zero division error [0] in div_s64_rem() called fromget_cycle_time_elapsed(), where sched->cycle_time is the divisor.We have tests in parse_taprio_schedule() so that cycle_time will neverbe 0, and actually cycle_time is not 0 in get_cycle_time_elapsed().The problem is that the types of divisor are different; cycle_time iss64, but the argument of div_s64_rem() is s32.syzkaller fed this input and 0x100000000 is cast to s32 to be 0. @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}We use s64 for cycle_time to cast it to ktime_t, so let's keep it andset max for cycle_time.While at it, we prevent overflow in setup_txtime() and add anothertest in parse_taprio_schedule() to check if cycle_time overflows.Also, we add a new tdc test case for this issue.[0]:divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 1 PID: 103 Comm: kworker/1:3 Not tainted 6.5.0-rc1-00330-g60cc1f7d0605 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:div_s64_rem include/linux/math64.h:42 [inline]RIP: 0010:get_cycle_time_elapsed net/sched/sch_taprio.c:223 [inline]RIP: 0010:find_entry_to_transmit+0x252/0x7e0 net/sched/sch_taprio.c:344Code: 3c 02 00 0f 85 5e 05 00 00 48 8b 4c 24 08 4d 8b bd 40 01 00 00 48 8b 7c 24 48 48 89 c8 4c 29 f8 48 63 f7 48 99 48 89 74 24 70 <48> f7 fe 48 29 d1 48 8d 04 0f 49 89 cc 48 89 44 24 20 49 8d 85 10RSP: 0018:ffffc90000acf260 EFLAGS: 00010206RAX: 177450e0347560cf RBX: 0000000000000000 RCX: 177450e0347560cfRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000100000000RBP: 0000000000000056 R08: 0000000000000000 R09: ffffed10020a0934R10: ffff8880105049a7 R11: ffff88806cf3a520 R12: ffff888010504800R13: ffff88800c00d800 R14: ffff8880105049a0 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0edf84f0e8 CR3: 000000000d73c002 CR4: 0000000000770ee0PKRU: 55555554Call Trace: get_packet_txtime net/sched/sch_taprio.c:508 [inline] taprio_enqueue_one+0x900/0xff0 net/sched/sch_taprio.c:577 taprio_enqueue+0x378/0xae0 net/sched/sch_taprio.c:658 dev_qdisc_enqueue+0x46/0x170 net/core/dev.c:3732 __dev_xmit_skb net/core/dev.c:3821 [inline] __dev_queue_xmit+0x1b2f/0x3000 net/core/dev.c:4169 dev_queue_xmit include/linux/netdevice.h:3088 [inline] neigh_resolve_output net/core/neighbour.c:1552 [inline] neigh_resolve_output+0x4a7/0x780 net/core/neighbour.c:1532 neigh_output include/net/neighbour.h:544 [inline] ip6_finish_output2+0x924/0x17d0 net/ipv6/ip6_output.c:135 __ip6_finish_output+0x620/0xaa0 net/ipv6/ip6_output.c:196 ip6_finish_output net/ipv6/ip6_output.c:207 [inline] NF_HOOK_COND include/linux/netfilter.h:292 [inline] ip6_output+0x206/0x410 net/ipv6/ip6_output.c:228 dst_output include/net/dst.h:458 [inline] NF_HOOK.constprop.0+0xea/0x260 include/linux/netfilter.h:303 ndisc_send_skb+0x872/0xe80 net/ipv6/ndisc.c:508 ndisc_send_ns+0xb5/0x130 net/ipv6/ndisc.c:666 addrconf_dad_work+0xc14/0x13f0 net/ipv6/addrconf.c:4175 process_one_work+0x92c/0x13a0 kernel/workqueue.c:2597 worker_thread+0x60f/0x1240 kernel/workqueue.c:2748 kthread+0x2fe/0x3f0 kernel/kthread.c:389 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 Modules linked in:
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential oops in cifs_oplock_breakWith deferred close we can have closes that race with lease breaks,and so with the current checks for whether to send the lease response,oplock_response(), this can mean that an unmount (kill_sb) can occurjust before we were checking if the tcon->ses is valid. See below:[Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs][Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39[Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206[Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009[Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188[Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900[Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138[Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000[Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000[Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0[Fri Aug 4 04:12:50 2023] Call Trace:[Fri Aug 4 04:12:50 2023] [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0[Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0[Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0[Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150[Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50[Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30[Fri Aug 4 04:12:50 2023] To fix this change the ordering of the checks before sending the oplock_responseto first check if the openFileList is empty.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add missing gfx11 MQD manager callbacksmqd_stride function was introduced in commit 2f77b9a242a2("drm/amdkfd: Update MQD management on multi XCC setup")but not assigned for gfx11. Fixes a NULL dereference in debugfs.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DPFixes OOPS on boards with ANX9805 DP encoders.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/sysv: Null check to prevent null-ptr-deref bugsb_getblk(inode->i_sb, parent) return a null ptr and taking lock onthat leads to the null-ptr-deref bug.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_netCommit f5f9d4a314da ("nfsd: move reply cache initialization into nfsdstartup") moved the initialization of the reply cache into nfsd startup,but didn't account for the stats counters, which can be accessed beforenfsd is ever started. The result can be a NULL pointer dereference whensomeone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is stillshut down.This is a regression and a user-triggerable oops in the right situation:- non-x86_64 arch- /proc/fs/nfsd is mounted in the namespace- nfsd is not started in the namespace- unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"Although this is easy to trigger on some arches (like aarch64), onx86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to thefixed_percpu_data. That struct looks just enough like a newlyinitialized percpu var to allow nfsd_reply_cache_stats_show to accessit without Oopsing.Move the initialization of the per-net+per-cpu reply-cache countersback into nfsd_init_net, while leaving the rest of the reply cacheallocations to be done at nfsd startup time.Kudos to Eirik who did most of the legwork to track this down.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: release path before inode lookup during the ino lookup ioctlDuring the ino lookup ioctl we can end up calling btrfs_iget() to get aninode reference while we are holding on a root's btree. If btrfs_iget()needs to lookup the inode from the root's btree, because it's notcurrently loaded in memory, then it will need to lock another or thesame path in the same root btree. This may result in a deadlock andtrigger the following lockdep splat: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted ------------------------------------------------------ syz-executor277/5012 is trying to acquire lock: ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 but task is already holding lock: ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302 btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955 btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline] btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338 btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline] open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494 btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154 btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 fc_mount fs/namespace.c:1112 [inline] vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142 btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 do_new_mount+0x28f/0xae0 fs/namespace.c:3335 do_mount fs/namespace.c:3675 [inline] __do_sys_mount fs/namespace.c:3884 [inline] __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861 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/0xcd -> #0 (btrfs-tree-01){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline] btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281 btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline] btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412 btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline] btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716 btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline] btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105 btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856 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/0xcd other info ---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix NULL dereference in error handlingSmatch reported:drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()warn: missing unwind goto?At this point in the function, nothing has been allocated so we can returndirectly. In particular the "qedf->global_queues" have not been allocatedso calling qedf_free_global_queues() will lead to a NULL dereference whenwe check if (!gl[i]) and "gl" is NULL.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:firmware: meson_sm: fix to avoid potential NULL pointer dereferenceof_match_device() may fail and returns a NULL pointer.Fix this by checking the return value of of_match_device.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/powernv/sriov: perform null check on iov before dereferencing iovCurrently pointer iov is being dereferenced before the null check of iovwhich can lead to null pointer dereference errors. Fix this by moving theiov null check before the dereferencing.Detected using cppcheck static analysis:linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Eitherthe condition '!iov' is redundant or there is possible null pointerdereference: iov. [nullPointerRedundantCheck] num_vfs = iov->num_vfs; ^
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: at91-pio4: check return value of devm_kasprintf()devm_kasprintf() returns a pointer to dynamically allocated memory.Pointer could be NULL in case allocation fails. Check pointer validity.Identified with coccinelle (kmerr.cocci script).Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks")Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Don't access req_list while it's being manipulatedThe icc_lock mutex was split into separate icc_lock and icc_bw_lockmutexes in [1] to avoid lockdep splats. However, this didn't adequatelyprotect access to icc_node::req_list.The icc_set_bw() function will eventually iterate over req_list whileonly holding icc_bw_lock, but req_list can be modified while onlyholding icc_lock. This causes races between icc_set_bw(), of_icc_get(),and icc_put().Example A: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... Example B: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... Fix this by ensuring icc_bw_lock is always held before manipulatingicc_node::req_list. The additional places icc_bw_lock is held don'tperform any memory allocations, so we should still be safe from theoriginal lockdep splats that motivated the separate locks.[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix adding block group to a reclaim list and the unused list during reclaimThere is a potential parallel list adding for retrying inbtrfs_reclaim_bgs_work and adding to the unused list. Since the blockgroup is removed from the reclaim list and it is on a relocation work,it can be added into the unused list in parallel. When that happens,adding it to the reclaim list will corrupt the list head and triggerlist corruption like below.Fix it by taking fs_info->unused_bgs_lock. [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104 [177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0) [177.529][T2585409] ------------[ cut here ]------------ [177.537][T2585409] kernel BUG at lib/list_debug.c:65! [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G W 6.10.0-rc5-kts #1 [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022 [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs] [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72 [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286 [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000 [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40 [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08 [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0 [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000 [177.687][T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000 [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0 [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000 [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400 [177.742][T2585409] PKRU: 55555554 [177.748][T2585409] Call Trace: [177.753][T2585409] [177.759][T2585409] ? __die_body.cold+0x19/0x27 [177.766][T2585409] ? die+0x2e/0x50 [177.772][T2585409] ? do_trap+0x1ea/0x2d0 [177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.788][T2585409] ? do_error_trap+0xa3/0x160 [177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.805][T2585409] ? handle_invalid_op+0x2c/0x40 [177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.820][T2585409] ? exc_invalid_op+0x2d/0x40 [177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20 [177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]There is a similar retry_list code in btrfs_delete_unused_bgs(), but it issafe, AFAICS. Since the block group was in the unused list, the used bytesshould be 0 when it was added to the unused list. Then, it checksblock_group->{used,reserved,pinned} are still 0 under theblock_group->lock. So, they should be still eligible for the unused list,not the reclaim list.The reason it is safe there it's because because we're holdingspace_info->groups_sem in write mode.That means no other task can allocate from the block group, so while weare at deleted_unused_bgs() it's not possible for other tasks toallocate and deallocate extents from the block group, so it can't beadded to the unused list or the reclaim list by anyone else.The bug can be reproduced by btrfs/166 after a few rounds. In practicethis can be hit when relocation cannot find more chunk space and endswith ENOSPC.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: fix fault at system suspend if device was already runtime suspendedIf the device was already runtime suspended then during system suspendwe cannot access the device registers else it will crash.Also we cannot access any registers after dwc3_core_exit() on someplatforms so move the dwc3_enable_susphy() call to the top.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Disable works on hci_unregister_devThis make use of disable_work_* on hci_unregister_dev since the hci_dev isabout to be freed new submissions are not disarable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix __apply_microcode_amd()'s return valueWhen verify_sha256_digest() fails, __apply_microcode_amd() should propagatethe failure by returning false (and not -1 which is promoted to true).
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix invalid pointer dereference in Etron workaroundThis check is performed before prepare_transfer() and prepare_ring(), soenqueue can already point at the final link TRB of a segment. And indeedit will, some 0.4% of times this code is called.Then enqueue + 1 is an invalid pointer. It will crash the kernel rightaway or load some junk which may look like a link TRB and cause the reallink TRB to be replaced with a NOOP. This wouldn't end well.Use a functionally equivalent test which doesn't dereference the pointerand always gives correct result.Something has crashed my machine twice in recent days while playing withan Etron HC, and a control transfer stress test ran for confirmation hasjust crashed it again. The same test passes with this patch applied.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: Optimize module load time by optimizing PLT/GOT countingWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD andCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,the relevant logs are as follows:rcu: INFO: rcu_sched self-detected stall on CPU...Call Trace:[<900000000024f9e4>] show_stack+0x5c/0x180[<90000000002482f4>] dump_stack_lvl+0x94/0xbc[<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280[<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88[<9000000000396c34>] update_process_times+0xb4/0x150[<90000000003b2474>] tick_nohz_handler+0xf4/0x250[<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428[<9000000000399b2c>] hrtimer_interrupt+0x214/0x538[<9000000000253634>] constant_timer_interrupt+0x64/0x80[<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0[<9000000000349a78>] handle_irq_event_percpu+0x18/0x88[<9000000000354c00>] handle_percpu_irq+0x90/0xf0[<9000000000348c74>] handle_irq_desc+0x94/0xb8[<9000000001012b28>] handle_cpu_irq+0x68/0xa0[<9000000001def8c0>] handle_loongarch_irq+0x30/0x48[<9000000001def958>] do_vint+0x80/0xd0[<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0[<90000000006344f4>] __asan_load8+0x4c/0x120[<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8[<90000000003895f0>] load_module+0x9e0/0x2958[<900000000038b770>] __do_sys_init_module+0x208/0x2d0[<9000000001df0c34>] do_syscall+0x94/0x190[<900000000024d6fc>] handle_syscall+0xbc/0x158After analysis, this is because the slow speed of loading the amdgpumodule leads to the long time occupation of the cpu and then the softdeadlock.When loading a module, module_frob_arch_sections() tries to figure outthe number of PLTs/GOTs that will be needed to handle all the RELAs. Itwill call the count_max_entries() to find in an out-of-order date whichcounting algorithm has O(n^2) complexity.To make it faster, we sort the relocation list by info and addend. Thatway, to check for a duplicate relocation, it just needs to compare withthe previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize moduleload time by optimizing PLT counting"). This gives sinificant reductionin module load time for modules with large number of relocations.After applying this patch, the soft deadlock problem has been solved,and the kernel starts normally without "Call Trace".Using the default configuration to test some modules, the results are asfollows:Module Sizeip_tables 36Kfat 143Kradeon 2.5MBamdgpu 16MBWithout this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 54 1221/84amdgpu 1411 4525/1098With this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 22 1221/84amdgpu 45 4525/1098
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix invalid accesses to ceph_connection_v1_infoThere is a place where generic code in messenger.c is reading andanother place where it is writing to con->v1 union member withoutchecking that the union member is active (i.e. msgr1 is in use).On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,so such a read is almost guaranteed to return a bogus value instead of0 when msgr2 is in use. This ends up being fairly benign because theside effect is just the invalidation of the authorizer and successivefetching of new tickets.con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact thatit's being written to can cause more serious consequences, but luckilyit's not something that happens often.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask andalways allocate memory using the hardcoded GFP_KERNEL flag. This makesthem inconsistent with vmalloc(), which was recently extended to supportGFP_NOFS and GFP_NOIO allocations.Page table allocations performed during shadow population also ignore theexternal gfp_mask. To preserve the intended semantics of GFP_NOFS andGFP_NOIO, wrap the apply_to_page_range() calls into the appropriatememalloc scope.xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.There was a report herehttps://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.comThis patch: - Extends kasan_populate_vmalloc() and helpers to take gfp_mask; - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page(); - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore() around apply_to_page_range(); - Updates vmalloc.c and percpu allocator call sites accordingly.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.syzbot reported the splat below. [0]The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytesAt 5., the data is carried over to the next sendmsg() as it issmaller than the cork_bytes specified by bpf_msg_cork_bytes().Then, tcp_bpf_send_verdict() tries to allocate psock->cork to holdthe data, but this fails silently due to fault injection + __GFP_NOWARN.If the allocation fails, we need to revert the sk->sk_forward_allocchange done by sk_msg_alloc().Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocatepsock->cork.The "*copied" also needs to be updated such that a proper error canbe returned to the caller, sendmsg. It fails to allocate psock->cork.Nothing has been corked so far, so this patch simply sets "*copied"to 0.[0]:WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983Modules linked in:CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fcRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: Take a reference on the task in struct vhost_task.vhost_task_create() creates a task and keeps a reference to itstask_struct. That task may exit early via a signal and its task_structwill be released.A pending vhost_task_wake() will then attempt to wake the task andaccess a task_struct which is no longer there.Acquire a reference on the task_struct while creating the thread andrelease the reference while the struct vhost_task itself is removed.If the task exits early due to a signal, then the vhost_task_wake() willstill access a valid task_struct. The wake is safe and will be skippedin this case.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULLcheck, which could lead to a null pointer dereference. Move the pruassignment, ensuring we never dereference a NULL rproc pointer.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix missing pointer check in hda_component_manager_init functionThe __component_match_add function may assign the 'matchptr' pointerthe value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.The call stack leading to the error looks like this:hda_component_manager_init|-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign|-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereferenceAdd IS_ERR() check to prevent the crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() pathsThe usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()path is very broken.sys_prlimit64() does get_task_struct(tsk) but this only protects task_structitself. If tsk != current and tsk is not a leader, this process can exit/execand task_lock(tsk->group_leader) may use the already freed task_struct.Another problem is that sys_prlimit64() can race with mt-exec which changes->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)->group_leader may change between task_lock() and task_unlock().Change sys_prlimit64() to take tasklist_lock when necessary. This is notnice, but I don't see a better fix for -stable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: Rework user message limit handlingThe limit on the number of user messages had a number of issues,improper counting in some cases and a use after free.Restructure how this is all done to handle more in the receive messageallocation routine, so all refcouting and user message limit countsare done in that routine. It's a lot cleaner and safer.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: Fix use-after-free in hdm_disconnecthdm_disconnect() calls most_deregister_interface(), which eventuallyunregisters the MOST interface device with device_unregister(iface->dev).If that drops the last reference, the device core may call release_mdev()immediately while hdm_disconnect() is still executing.The old code also freed several mdev-owned allocations inhdm_disconnect() and then performed additional put_device() calls.Depending on refcount order, this could lead to use-after-free ordouble-free when release_mdev() ran (or when unregister paths alsoperformed puts).Fix by moving the frees of mdev-owned allocations into release_mdev(),so they happen exactly once when the device is truly released, and bydropping the extra put_device() calls in hdm_disconnect() that areredundant after device_unregister() and most_deregister_interface().This addresses the KASAN slab-use-after-free reported by syzbot inhdm_disconnect(). See report and stack traces in the bug link below.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: fix lock inversion in vsock_assign_transport()Syzbot reported a potential lock inversion deadlock betweenvsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.The issue was introduced by commit 687aa0c5581b ("vsock: Fixtransport_* TOCTOU") which added vsock_register_mutex locking invsock_assign_transport() around the transport->release() call, that cancall vsock_linger(). vsock_assign_transport() can be called with sk_lockheld. vsock_linger() calls sk_wait_event() that temporarily releases andre-acquires sk_lock. During this window, if another thread holdvsock_register_mutex while trying to acquire sk_lock, a circulardependency is created.Fix this by releasing vsock_register_mutex before callingtransport->release() and vsock_deassign_transport(). This is safebecause we don't need to hold vsock_register_mutex while releasing theold transport, and we ensure the new transport won't disappear byobtaining a module reference first via try_module_get().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: rate: Unset parent pointer in devl_rate_nodes_destroyThe function devl_rate_nodes_destroy is documented to "Unset parent forall rate objects". However, it was only calling the driver-specific`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementingthe parent's refcount, without actually setting the`devlink_rate->parent` pointer to NULL.This leaves a dangling pointer in the `devlink_rate` struct, which causerefcount error in netdevsim[1] and mlx5[2]. In addition, this isinconsistent with the behavior of `devlink_nl_rate_parent_node_set`,where the parent pointer is correctly cleared.This patch fixes the issue by explicitly setting `devlink_rate->parent`to NULL after notifying the driver, thus fulfilling the function'sdocumented behavior for all rate objects.[1]repro steps:echo 1 > /sys/bus/netdevsim/new_devicedevlink dev eswitch set netdevsim/netdevsim1 mode switchdevecho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfsdevlink port function rate add netdevsim/netdevsim1/test_nodedevlink port function rate set netdevsim/netdevsim1/128 parent test_nodeecho 1 > /sys/bus/netdevsim/del_devicedmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2]devlink dev eswitch set pci/0000:08:00.0 mode switchdevdevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000devlink port function rate add pci/0000:08:00.0/group1devlink port function rate set pci/0000:08:00.0/32768 parent group1modprobe -r mlx5_ib mlx5_fwctl mlx5_coredmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: remove never-working support for setting nsh fieldsThe validation of the set(nsh(...)) action is completely wrong.It runs through the nsh_key_put_from_nlattr() function that is thesame function that validates NSH keys for the flow match and thepush_nsh() action. However, the set(nsh(...)) has a very differentmemory layout. Nested attributes in there are doubled in size incase of the masked set(). That makes proper validation impossible.There is also confusion in the code between the 'masked' flag, thatsays that the nested attributes are doubled in size containing boththe value and the mask, and the 'is_mask' that says that the valuewe're parsing is the mask. This is causing kernel crash on trying towrite into mask part of the match with SW_FLOW_KEY_PUT() duringvalidation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe third issue with this process is that while trying to convertthe non-masked set into masked one, validate_set() copies and doublesthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nestedattributes. It should be copying each nested attribute and doublingthem in size independently. And the process must be properly reversedduring the conversion back from masked to a non-masked variant duringthe flow dump.In the end, the only two outcomes of trying to use this action areeither validation failure or a kernel crash. And if somehow someonemanages to install a flow with such an action, it will most definitelynot do what it is supposed to, since all the keys and the masks aremixed up.Fixing all the issues is a complex task as it requires re-writingmost of the validation code.Given that and the fact that this functionality never worked sinceintroduction, let's just remove it altogether. It's better tore-introduce it later with a proper implementation instead of tryingto fix it in stable releases.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never addedIn commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), Imissed the case where state creation fails between fullinitialization (->init_state has been called) and being inserted onthe lists.In this situation, ->init_state has been called, so for IPcomptunnels, the fallback tunnel has been created and added onto thelists, but the user state never gets added, because we fail beforethat. The user state doesn't go through __xfrm_state_delete, so wedon't call xfrm_state_delete_tunnel for those states, and we end upleaking the FB tunnel.There are several codepaths affected by this: the add/update paths, inboth net/key and xfrm, and the migrate code (xfrm_migrate,xfrm_state_migrate). A "proper" rollback of the init_state work wouldprobably be doable in the add/update code, but for migrate it getsmore complicated as multiple states may be involved.At some point, the new (not-inserted) state will be destroyed, so callxfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most stateswill have their fallback tunnel cleaned up during __xfrm_state_delete,which solves the issue that b441cf3f8c4b (and other patches before it)aimed at. All states (including FB tunnels) will be removed from thelists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Input: imx_sc_key - fix memory corruption on unloadThis is supposed to be "priv" but we accidentally pass "&priv" which isan address in the stack and so it will lead to memory corruption whenthe imx_sc_key_action() function is called. Remove the &.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Input: cros_ec_keyb - fix an invalid memory accessIf cros_ec_keyb_register_matrix() isn't called (due to`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remainsNULL. An invalid memory access is observed in cros_ec_keyb_process()when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_threadIt's still unknown about why the kernel receives such malformed event,in any cases, the kernel shouldn't access `ckdev->idev` and friends ifthe driver doesn't intend to initialize them.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix use-after-free race in fault handlerWhen a page fault occurs in a secret memory file created with`memfd_secret(2)`, the kernel will allocate a new folio for it, mark theunderlying page as not-present in the direct map, and add it to the filemapping.If two tasks cause a fault in the same page concurrently, both could endup allocating a folio and removing the page from the direct map, but onlyone would succeed in adding the folio to the file mapping. The task thatfailed undoes the effects of its attempt by (a) freeing the folio againand (b) putting the page back into the direct map. However, by doingthese two operations in this order, the page becomes available to theallocator again before it is placed back in the direct mapping.If another task attempts to allocate the page between (a) and (b), and thekernel tries to access it via the direct map, it would result in asupervisor not-present page fault.Fix the ordering to restore the direct map before the folio is freed.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dyingWhen unbinding a memslot from a guest_memfd instance, remove the bindingseven if the guest_memfd file is dying, i.e. even if its file refcount hasgone to zero. If the memslot is freed before the file is fully released,nullifying the memslot side of the binding in kvm_gmem_release() willwrite to freed memory, as detected by syzbot+KASAN: ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022 CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call 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 kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 __fput+0x44c/0xa70 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xe9/0x130 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+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbeeff8efc9 Allocated by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 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 Freed by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2533 [inline] slab_free mm/slub.c:6622 [inline] kfree+0x19a/0x6d0 mm/slub.c:6829 kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 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/0x7fDeliberately don't acquire filemap invalid lock when the file is dying asthe lifecycle of f_mapping is outside the purview of KVM. Dereferencingthe mapping is *probably* fine, but there's no need to invalidate anythingas memslot deletion is responsible for zapping SPTEs, and the only codethat can access the dying file is kvm_gmem_release(), whose core code ismutual---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix improper check of dentry.stream.valid_sizeWe found an infinite loop bug in the exFAT file system that can lead to aDenial-of-Service (DoS) condition. When a dentry in an exFAT filesystem ismalformed, the following system calls - SYS_openat, SYS_ftruncate, andSYS_pwrite64 - can cause the kernel to hang.Root cause analysis shows that the size validation code in exfat_find()does not check whether dentry.stream.valid_size is negative. As a result,the system calls mentioned above can succeed and eventually trigger the DoSissue.This patch adds a check for negative dentry.stream.valid_size to preventthis vulnerability.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devicesPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The rootcause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,but that `man->bdev` (the backing device pointer within the manager) remainsuninitialized (NULL) on APUs-since APUs lack dedicated VRAM and do not fullyset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts toacquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading toa kernel OOPS.1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately-skipping VRAM-specific logic that would trigger the NULL dereference.2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL.3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report).This approach is more robust than APU-specific checks because it:- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),- Aligns with TTM's design by using its native helper function,- Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check).v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAMOtherwise accessing them can cause a crash.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix xattr related buffer overflow...Willy Tarreau forwarded me a message fromDisclosure with the followingwarning:> The helper `xattr_key()` uses the pointer variable in the loop condition> rather than dereferencing it. As `key` is incremented, it remains non-NULL> (until it runs into unmapped memory), so the loop does not terminate on> valid C strings and will walk memory indefinitely, consuming CPU or hanging> the thread.I easily reproduced this with setfattr and getfattr, causing a kerneloops, hung user processes and corrupted orangefs files. Disclosuresent along a diff (not a patch) with a suggested fix, which I basedthis patch on.After xattr_key started working right, xfstest generic/069 exposed anxattr related memory leak that lead to OOM. xattr_key returnsa hashed key. When adding xattrs to the orangefs xattr cache, orangefsused hash_add, a kernel hashing macro. hash_add also hashes the key usinghash_log which resulted in additions to the xattr cache going to the wronghash bucket. generic/069 tortures a single file and orangefs does agetattr for the xattr "security.capability" every time. Orangefsnegative caches on xattrs which includes a kmalloc. Since adds to thexattr cache were going to the wrong bucket, every getattr for"security.capability" resulted in another kmalloc, none of which wereever freed.I changed the two uses of hash_add to hlist_add_head insteadand the memory leak ceased and generic/069 quit throwing furniture.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bcsp: receive data only if registeredCurrently, bcsp_recv() can be called even when the BCSP protocol has notbeen registered. This leads to a NULL pointer dereference, as shown inthe following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/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/0x7fTo prevent this, ensure that the HCI_UART_REGISTERED flag is set beforeprocessing received data. If the protocol is not registered, return-EUNATCH.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Verify inode mode when loading from diskThe inode mode loaded from corrupted disk can be invalid. Do like whatcommit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")does.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Fix epfile null pointer access after ep enable.A race condition occurs when ffs_func_eps_enable() runs concurrentlywith ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leadingto a NULL pointer dereference when accessing epfile->ep inffs_func_eps_enable() after successful usb_ep_enable().The ffs->epfiles pointer is set to NULL in both ffs_data_clear() andffs_data_close() functions, and its modification is protected by thespinlock ffs->eps_lock. And the whole ffs_func_eps_enable() functionis also protected by ffs->eps_lock.Thus, add NULL pointer handling for ffs->epfiles in theffs_func_eps_enable() function to fix issues
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix device use-after-free on unbindA recent change fixed device reference leaks when looking up drmplatform device driver data during bind() but failed to remove a partialfix which had been added by commit 80805b62ea5b ("drm/mediatek: Fixkobject put for component sub-drivers").This results in a reference imbalance on component bind() failures andon unbind() which could lead to a user-after-free.Make sure to only drop the references after retrieving the driver databy effectively reverting the previous partial fix.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:regmap: slimbus: fix bus_context pointer in regmap init callsCommit 4e65bda8273c ("ASoC: wcd934x: fix error handling inwcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.That commit breaks audio playback, for instance, on sdm845 ThundercommDragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19cThe __devm_regmap_init_slimbus() started to be used instead of__regmap_init_slimbus() after the commit mentioned above and turns outthe incorrect bus_context pointer (3rd argument) was used in__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equalto &slimbus->dev). Correct it. The wcd934x codec seems to be the only orthe first user of devm_regmap_init_slimbus() but we should fix it tillthe point where __devm_regmap_init_slimbus() was introduced thereforetwo "Fixes" tags.While at this, also correct the same argument in __regmap_init_slimbus().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_oncehci_cmd_sync_dequeue_once() does lookup and then cancelthe entry under two separate lock sections. Meanwhile,hci_cmd_sync_work() can also delete the same entry,leading to double list_del() and "UAF".Fix this by holding cmd_sync_work_lock across bothlookup and cancel, so that the entry cannot be removedconcurrently.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Sync pending IRQ work before freeing ring bufferFix a race where irq_work can be queued in bpf_ringbuf_commit()but the ring buffer is freed before the work executes.In the syzbot reproducer, a BPF program attached to sched_switchtriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring bufferis freed before this work executes, the irq_work thread may accessesfreed memory.Calling `irq_work_sync(&rb->work)` ensures that all pending irq_workcomplete before freeing the buffer.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential cfid UAF in smb2_query_info_compoundWhen smb2_query_info_compound() retries, a previously allocated cfid mayhave been freed in the first attempt.Because cfid wasn't reset on replay, later cleanup could act on a stalepointer, leading to a potential use-after-free.Reinitialize cfid to NULL under the replay label.Example trace (trimmed):refcount_t: underflow; use-after-free.WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110[...]RIP: 0010:refcount_warn_saturate+0x9c/0x110[...]Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix crash in nfsd4_read_release()When tracing is enabled, the trace_nfsd_read_done trace pointcrashes during the pynfs read.testNoFh test.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_close_cached_fid()find_or_create_cached_dir() could grab a new reference after kref_put()had seen the refcount drop to zero but before cfid_list_lock is acquiredin smb2_close_cached_fid(), leading to use-after-free.Switch to kref_put_lock() so cfid_release() is called withcfid_list_lock held, closing that gap.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cbThe Mesa issue referenced below pointed out a possible deadlock:[ 1231.611031] Possible interrupt unsafe locking scenario:[ 1231.611033] CPU0 CPU1[ 1231.611034] ---- ----[ 1231.611035] lock(&xa->xa_lock#17);[ 1231.611038] local_irq_disable();[ 1231.611039] lock(&fence->lock);[ 1231.611041] lock(&xa->xa_lock#17);[ 1231.611044] [ 1231.611045] lock(&fence->lock);[ 1231.611047] *** DEADLOCK ***In this example, CPU0 would be any function accessing job->dependenciesthrough the xa_* functions that don't disable interrupts (eg:drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signallingcallback so in an interrupt context. It will deadlock when trying tograb the xa_lock which is already held by CPU0.Replacing all xa_* usage by their xa_*_irq counterparts would fixthis issue, but Christian pointed out another issue: dma_fence_signaltakes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lockThis will deadlock if f1 and f2 share the same spinlock.To fix both issues, the code iterating on dependencies and re-arming themis moved out to drm_sched_entity_kill_jobs_work().[phasta: commit message nits]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()which causes the code to proceed with NULL clock pointers. The currentlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for bothvalid pointers and NULL, leading to potential NULL pointer dereferencein clk_get_rate().Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:"The error code within @ptr if it is an error pointer; 0 otherwise."This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULLpointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to becalled when of_clk_get() returns NULL.Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for validpointers, preventing potential NULL pointer dereference in clk_get_rate().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: fix the deadlock of enetc_mdio_lockAfter applying the workaround for err050089, the LS1028A platformexperiences RCU stalls on RT kernel. This issue is caused by therecursive acquisition of the read lock enetc_mdio_lock. Here list someof the call stacks identified under the enetc_poll path that may lead toa deadlock:enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdioAfter enetc_poll acquires the read lock, a higher-priority writer attemptsto acquire the lock, causing preemption. The writer detects that aread lock is already held and is scheduled out. However, readers underenetc_poll cannot acquire the read lock again because a writer is alreadywaiting, leading to a thread hang.Currently, the deadlock is avoided by adjusting enetc_lock_mdio to preventrecursive lock acquisition.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQXDP programs can change the layout of an xdp_buff throughbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the drivercannot assume the size of the linear data area nor fragments. Fix thebug in mlx5 by generating skb according to xdp_buff after XDP programsrun.Currently, when handling multi-buf XDP, the mlx5 driver assumes thelayout of an xdp_buff to be unchanged. That is, the linear data areacontinues to be empty and fragments remain the same. This may causethe driver to generate erroneous skb or triggering a kernelwarning. When an XDP program added linear data throughbpf_xdp_adjust_head(), the linear data will be ignored asmlx5e_build_linear_skb() builds an skb without linear data and thenpull data from fragments to fill the linear data area. When an XDPprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),the delta passed to __pskb_pull_tail() may exceed the actual nonlineardata size and trigger the BUG_ON in it.To fix the issue, first record the original number of fragments. If thenumber of fragments changes after the XDP program runs, rewind the endfragment pointer by the difference and recalculate the truesize. Then,build the skb with the linear data area matching the xdp_buff. Finally,only pull data in if there is non-linear data and fill the linear partup to 256 bytes.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sysfb: Do not dereference NULL pointer in plane resetThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do notderef that pointer, but forward NULL to the other plane-reset helpers.Clears plane->state to NULL.v2:- fix typo in commit description (Javier)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix uninitialized waitqueue in transaction managerThe transaction manager initialization in txInit() was not properlyinitializing TxBlock[0].waitor waitqueue, causing a crash whentxEnd(0) is called on read-only filesystems.When a filesystem is mounted read-only, txBegin() returns tid=0 toindicate no transaction. However, txEnd(0) still gets called andtries to access TxBlock[0].waitor via tid_to_tblock(0), but thiswaitqueue was never initialized because the initialization loopstarted at index 1 instead of 0.This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEndFix by ensuring all transaction blocks including TxBlock[0] havetheir waitqueues properly initialized during txInit().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure XFD state on signal deliverySean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Chao further identified [2] a reproducible scenario involving signaldelivery: a non-AMX task is preempted by an AMX-enabled task whichmodifies the XFD MSR.When the non-AMX task resumes and reloads XSTATE with init values,a warning is triggered due to a mismatch between fpstate::xfd and theCPU's current XFD state. fpu__clear_user_states() does not currentlyre-synchronize the XFD state after such preemption.Invoke xfd_update_state() which detects and corrects the mismatch ifthere is a dynamic feature.This also benefits the sigreturn path, as fpu__restore_sig() may callfpu__clear_user_states() when the sigframe is inaccessible.[ dhansen: minor changelog munging ]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: aspeed - fix double free caused by devmThe clock obtained via devm_clk_get_enabled() is automatically managedby devres and will be disabled and freed on driver detach. Manuallycalling clk_disable_unprepare() in error path and remove functioncauses double free.Remove the manual clock cleanup in both aspeed_acry_probe()'s errorpath and aspeed_acry_remove().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: cadence: Check for the existence of cdns_pcie::ops before using itcdns_pcie::ops might not be populated by all the Cadence glue drivers. Thisis going to be true for the upcoming Sophgo platform which doesn't set theops.Hence, add a check to prevent NULL pointer dereference.[mani: reworded subject and description]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: fix possible deadlock while configuring policyFollowing deadlock can be triggered easily by lockdep:WARNING: possible circular locking dependency detected6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted------------------------------------------------------check/1334 is trying to acquire lock:ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180but task is already holding lock:ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7eother info that might help us debug this:Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);Root cause is that queue_usage_counter is grabbed with rq_qos_mutexheld in blkg_conf_prep(), while queue should be freezed beforerq_qos_mutex from other context.The blk_queue_enter() from blkg_conf_prep() is used to protect againstpolicy deactivation, which is already protected with blkcg_mutex, henceconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,consider that blkcg_mutex is held after queue is freezed from policydeactivation, also convert blkg_alloc() to use GFP_NOIO.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()kcalloc() may fail. When WS is non-zero and allocation fails, ectx.wsremains NULL while ectx.ws_size is set, leading to a potential NULLpointer dereference in atom_get_src_int() when accessing WS entries.Return -ENOMEM on allocation failure to avoid the NULL dereference.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: imon: make send_packet() more robustsyzbot is reporting that imon has three problems which result inhung tasks due to forever holding device lock [1].First problem is that when usb_rx_callback_intf0() once got -EPROTO errorafter ictx->dev_present_intf0 became true, usb_rx_callback_intf0()resubmits urb after printk(), and resubmitted urb causesusb_rx_callback_intf0() to again get -EPROTO error. This results inprintk() flooding (RCU stalls).Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away.but imon has a poor error-recovery scheme which just retries forever;this behavior should be fixed.Since I'm not sure whether it is safe for imon users to give up upon anyerror code, this patch takes care of only union of error codes chosen frommodules in drivers/media/rc/ directory which handle -EPROTO error (i.e.ir_toy, mceusb and igorplugusb).Second problem is that when usb_rx_callback_intf0() once got -EPROTO errorbefore ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() alwaysresubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedgehardware after early callbacks"). Move the ictx->dev_present_intf0 testintroduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodesuntil intf configured") to immediately before imon_incoming_packet(), orthe first problem explained above happens without printk() flooding (i.e.hung task).Third problem is that when usb_rx_callback_intf0() is not called for somereason (e.g. flaky hardware; the reproducer for this problem sometimesprevents usb_rx_callback_intf0() from being called),wait_for_completion_interruptible() in send_packet() never returns (i.e.hung task). As a workaround for such situation, change send_packet() towait for completion with timeout of 10 seconds.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcodeRunning x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an outof bounds access.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add bpf_prog_run_data_pointers()syzbot found that cls_bpf_classify() is able to changetc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:Extend qdisc control block with tc control block"), which added a wronginteraction with db58ba459202 ("bpf: wire in data and data_end forcls_act_bpf").drop_reason was added later.Add bpf_prog_run_data_pointers() helper to save/restore the net_schedstorage colliding with BPF data_meta/data_end.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: remove two invalid BUG_ON()sThose can be triggered trivially by userspace.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mlx5: Fix default values in create CQCurrently, CQs without a completion function are assigned themlx5_add_cq_to_tasklet function by default. This is problematic sinceonly user CQs created through the mlx5_ib driver are intended to usethis function.Additionally, all CQs that will use doorbells instead of polling forcompletions must call mlx5_cq_arm. However, the default CQ creation flowleaves a valid value in the CQ's arm_db field, allowing FW to sendinterrupts to polling-only CQs in certain corner cases.These two factors would allow a polling-only kernel CQ to be triggeredby an EQ interrupt and call a completion function intended only for userCQs, causing a null pointer exception.Some areas in the driver have prevented this issue with one-off fixesbut did not address the root cause.This patch fixes the described issue by adding defaults to the create CQflow. It adds a default dummy completion function to protect againstnull pointer exceptions, and it sets an invalid command sequence numberby default in kernel CQs to prevent the FW from sending an interrupt tothe CQ until it is armed. User CQs are responsible for their owninitialization values.Callers of mlx5_core_create_cq are responsible for changing thecompletion function and arming the CQ per their needs.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Input: pegasus-notetaker - fix potential out-of-bounds accessIn the pegasus_notetaker driver, the pegasus_probe() function allocatesthe URB transfer buffer using the wMaxPacketSize value fromthe endpoint descriptor. An attacker can use a malicious USB descriptorto force the allocation of a very small buffer.Subsequently, if the device sends an interrupt packet with a specificpattern (e.g., where the first byte is 0x80 or 0x42),the pegasus_parse_packet() function parses the packet without checkingthe allocated buffer size. This leads to an out-of-bounds memory access.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: fix lockdep WARN due to partition scan workBlktests test cases nvme/014, 057 and 058 fail occasionally due to alockdep WARN. As reported in the Closes tag URL, the WARN indicates thata deadlock can happen due to the dependency among disk->open_mutex,kblockd workqueue completion and partition_scan_work completion.To avoid the lockdep WARN and the potential deadlock, cut the dependencyby running the partition_scan_work not by kblockd workqueue but bynvme_wq.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_descs32_pinctrl_desc is allocated with devm_kmalloc(), but not all of itsfields are initialized. Notably, num_custom_params is used inpinconf_generic_parse_dt_config(), resulting in intermittent allocationerrors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...]This results in later parse failures that can cause issues in dependentdrivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registeredFix this by initializing s32_pinctrl_desc with devm_kzalloc() instead ofdevm_kmalloc() in s32_pinctrl_probe(), which sets the previouslyuninitialized fields to zero.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Fix proto fallback detection with BPFThe sockmap feature allows bpf syscall from userspace, or basedon bpf sockops, replacing the sk_prot of sockets during protocol stackprocessing with sockmap's custom read/write interfaces.'''tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot'''When the server has MPTCP enabled but the client sends a TCP SYNwithout MPTCP, subflow_syn_recv_sock() performs a fallback on thesubflow, replacing the subflow sk's sk_prot with the native sk_prot.'''subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override()'''Then, this subflow can be normally used by sockmap, which replaces thenative sk_prot with sockmap's custom sk_prot. The issue occurs when theuser executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().Here, it uses sk->sk_prot to compare with the native sk_prot, but thisis incorrect when sockmap is used, as we may incorrectly setsk->sk_socket->ops.This fix uses the more generic sk_family for the comparison instead.Additionally, this also prevents a WARNING from occurring:result from ./scripts/decode_stacktrace.sh:------------[ cut here ]------------WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \(net/mptcp/protocol.c:4005)Modules linked in:...PKRU: 55555554Call Trace:do_accept (net/socket.c:1989)__sys_accept4 (net/socket.c:2028 net/socket.c:2057)__x64_sys_accept (net/socket.c:2067)x64_sys_call (arch/x86/entry/syscall_64.c:41)do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)RIP: 0033:0x7f87ac92b83d---[ end trace 0000000000000000 ]---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix gpu page fault after hibernation on PF passthroughOn PF passthrough environment, after hibernate and then resume, coralgemmwill cause gpu page fault.Mode1 reset happens during hibernate, but partition mode is not restoredon resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not rightafter resume. When CP access the MQD BO, wrong stride size is used,this will cause out of bound access on the MQD BO, resulting page fault.The fix is to ensure gfx_v9_4_3_switch_compute_partition() is calledwhen resume from a hibernation.KFD resume is called separately during a reset recovery or resume fromsuspend sequence. Hence it's not required to be called as part ofpartition switch.(cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Add call to put_pid()Add a call to put_pid() corresponding to get_task_pid().host1x_memory_context_alloc() does not take ownership of the PID so weneed to free it here to avoid leaking.[mperttunen@nvidia.com: reword commit message]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::bootnvkm_falcon_fw::boot is allocated, but no one frees it. This causes akmemleak warning.Make sure this data is deallocated.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mtdchar: fix integer overflow in read/write ioctlsThe "req.start" and "req.len" variables are u64 values that come from theuser at the start of the function. We mask away the high 32 bits of"req.len" so that's capped at U32_MAX but the "req.start" variable can goup to U64_MAX which means that the addition can still integer overflow.Use check_add_overflow() to fix this bug.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: cadence: fix DMA device NULL pointer dereferenceThe DMA device pointer `dma_dev` was being dereferenced before ensuringthat `cdns_ctrl->dmac` is properly initialized.Move the assignment of `dma_dev` after successfully acquiring the DMAchannel to ensure the pointer is valid before use.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: restore write access before closing files opened by open_exec()bm_register_write() opens an executable file using open_exec(), whichinternally calls do_open_execat() and denies write access on the file toavoid modification while it is being executed.However, when an error occurs, bm_register_write() closes the file usingfilp_close() directly. This does not restore the write permission, whichmay cause subsequent write operations on the same file to fail.Fix this by calling exe_file_allow_write_access() before filp_close() torestore the write permission properly.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDOn completion of i915_vma_pin_ww(), a synchronous variant ofdma_fence_work_commit() is called. When pinning a VMA to GGTT addressspace on a Cherry View family processor, or on a Broxton generation SoCwith VTD enabled, i.e., when stop_machine() is then called fromintel_ggtt_bind_vma(), that can potentially lead to lock inversion amongreservation_ww and cpu_hotplug locks.[86.861179] ======================================================[86.861193] WARNING: possible circular locking dependency detected[86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U[86.861226] ------------------------------------------------------[86.861238] i915_module_loa/1432 is trying to acquire lock:[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50[86.861290]but task is already holding lock:[86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915][86.862233]which lock already depends on the new lock.[86.862251]the existing dependency chain (in reverse order) is:[86.862265]-> #5 (reservation_ww_class_mutex){+.+.}-{3:3}:[86.862292] dma_resv_lockdep+0x19a/0x390[86.862315] do_one_initcall+0x60/0x3f0[86.862334] kernel_init_freeable+0x3cd/0x680[86.862353] kernel_init+0x1b/0x200[86.862369] ret_from_fork+0x47/0x70[86.862383] ret_from_fork_asm+0x1a/0x30[86.862399]-> #4 (reservation_ww_class_acquire){+.+.}-{0:0}:[86.862425] dma_resv_lockdep+0x178/0x390[86.862440] do_one_initcall+0x60/0x3f0[86.862454] kernel_init_freeable+0x3cd/0x680[86.862470] kernel_init+0x1b/0x200[86.862482] ret_from_fork+0x47/0x70[86.862495] ret_from_fork_asm+0x1a/0x30[86.862509]-> #3 (&mm->mmap_lock){++++}-{3:3}:[86.862531] down_read_killable+0x46/0x1e0[86.862546] lock_mm_and_find_vma+0xa2/0x280[86.862561] do_user_addr_fault+0x266/0x8e0[86.862578] exc_page_fault+0x8a/0x2f0[86.862593] asm_exc_page_fault+0x27/0x30[86.862607] filldir64+0xeb/0x180[86.862620] kernfs_fop_readdir+0x118/0x480[86.862635] iterate_dir+0xcf/0x2b0[86.862648] __x64_sys_getdents64+0x84/0x140[86.862661] x64_sys_call+0x1058/0x2660[86.862675] do_syscall_64+0x91/0xe90[86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e[86.862703]-> #2 (&root->kernfs_rwsem){++++}-{3:3}:[86.862725] down_write+0x3e/0xf0[86.862738] kernfs_add_one+0x30/0x3c0[86.862751] kernfs_create_dir_ns+0x53/0xb0[86.862765] internal_create_group+0x134/0x4c0[86.862779] sysfs_create_group+0x13/0x20[86.862792] topology_add_dev+0x1d/0x30[86.862806] cpuhp_invoke_callback+0x4b5/0x850[86.862822] cpuhp_issue_call+0xbf/0x1f0[86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320[86.862852] __cpuhp_setup_state+0xb0/0x220[86.862866] topology_sysfs_init+0x30/0x50[86.862879] do_one_initcall+0x60/0x3f0[86.862893] kernel_init_freeable+0x3cd/0x680[86.862908] kernel_init+0x1b/0x200[86.862921] ret_from_fork+0x47/0x70[86.862934] ret_from_fork_asm+0x1a/0x30[86.862947]-> #1 (cpuhp_state_mutex){+.+.}-{3:3}:[86.862969] __mutex_lock+0xaa/0xed0[86.862982] mutex_lock_nested+0x1b/0x30[86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320[86.863012] __cpuhp_setup_state+0xb0/0x220[86.863026] page_alloc_init_cpuhp+0x2d/0x60[86.863041] mm_core_init+0x22/0x2d0[86.863054] start_kernel+0x576/0xbd0[86.863068] x86_64_start_reservations+0x18/0x30[86.863084] x86_64_start_kernel+0xbf/0x110[86.863098] common_startup_64+0x13e/0x141[86.863114]-> #0 (cpu_hotplug_lock){++++}-{0:0}:[86.863135] __lock_acquire+0x16---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: hdm_probe: Fix calling put_device() before device initializationThe early error path in hdm_probe() can jump to err_free_mdev before&mdev->dev has been initialized with device_initialize(). Callingput_device(&mdev->dev) there triggers a device core WARN and ends upinvoking kref_put(&kobj->kref, kobject_release) on an uninitializedkobject.In this path the private struct was only kmalloc'ed and the intendedrelease is effectively kfree(mdev) anyway, so free it directly insteadof calling put_device() on an uninitialized device.This removes the WARNING and fixes the pre-initialization error path.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookupIn fastrpc_map_lookup, dma_buf_get is called to obtain a reference tothe dma_buf for comparison purposes. However, this reference is neverreleased when the function returns, leading to a dma_buf memory leak.Fix this by adding dma_buf_put before returning from the function,ensuring that the temporarily acquired reference is properly releasedregardless of whether a matching map is found.Rule: add
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsingThe Extended Supported Rates (ESR) IE handling in OnBeacon accessed*(p + 1 + ielen) and *(p + 2 + ielen) without verifying that theseoffsets lie within the received frame buffer. A malformed beacon withan ESR IE positioned at the end of the buffer could cause anout-of-bounds read, potentially triggering a kernel panic.Add a boundary check to ensure that the ESR IE body and the subsequentbytes are within the limits of the frame before attempting to accessthem.This prevents OOB reads caused by malformed beacon frames.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parserThe Information Element (IE) parser rtw_get_ie() trusted the lengthbyte of each IE without validating that the IE body (len bytes afterthe 2-byte header) fits inside the remaining frame buffer. A malformedframe can advertise an IE length larger than the available data, causingthe parser to increment its pointer beyond the buffer end. This resultsin out-of-bounds reads or, depending on the pattern, an infinite loop.Fix by validating that (offset + 2 + len) does not exceed the limitbefore accepting the IE or advancing to the next element.This prevents OOB reads and ensures the parser terminates safely onmalformed frames.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: check device's attached status in compat ioctlsSyzbot identified an issue [1] that crashes kernel, seemingly due tounexistent callback dev->get_valid_routes(). By all means, this shouldnot occur as said callback must always be set toget_zero_valid_routes() in __comedi_device_postconfig().As the crash seems to appear exclusively in i386 kernels, at least,judging from [1] reports, the blame lies with compat versionsof standard IOCTL handlers. Several of them are modified anddo not use comedi_unlocked_ioctl(). While functionality of theseioctls essentially copy their original versions, they do nothave required sanity check for device's attached status. This,in turn, leads to a possibility of calling select IOCTLs on adevice that has not been properly setup, even via COMEDI_DEVCONFIG.Doing so on unconfigured devices means that several crucial stepsare missed, for instance, specifying dev->get_valid_routes()callback.Fix this somewhat crudely by ensuring device's attached status beforeperforming any ioctls, improving logic consistency between modernand compat functions.[1] Syzbot report:BUG: kernel NULL pointer dereference, address: 0000000000000000...CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0Call Trace: get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [inline] __se_compat_sys_ioctl fs/ioctl.c:638 [inline] __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]...
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replacedWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTninstruction, discard the exception and retry the instruction if the codestream is changed (e.g. by a different vCPU) between when the CPUexecutes the instruction and when KVM decodes the instruction to get thenext RIP.As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-injectINT3/INTO instead of retrying the instruction"), failure to verify thatthe correct INTn instruction was decoded can effectively clobber gueststate due to decoding the wrong instruction and thus specifying thewrong next RIP.The bug most often manifests as "Oops: int3" panics on static branchchecks in Linux guests. Enabling or disabling a static branch in Linuxuses the kernel's "text poke" code patching mechanism. To modify codewhile other CPUs may be executing that code, Linux (temporarily)replaces the first byte of the original instruction with an int3 (opcode0xcc), then patches in the new code stream except for the first byte,and finally replaces the int3 with the first byte of the new codestream. If a CPU hits the int3, i.e. executes the code while it's beingmodified, then the guest kernel must look up the RIP to determine how tohandle the #BP, e.g. by emulating the new instruction. If the RIP isincorrect, then this lookup fails and the guest kernel panics.The bug reproduces almost instantly by hacking the guest kernel torepeatedly check a static branch[1] while running a drgn script[2] onthe host to constantly swap out the memory containing the guest's TSS.[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix memory leak in eem_unwrapThe existing code did not handle the failure case of usb_ep_queue in thecommand path, potentially leading to memory leaks.Improve error handling to free all allocated resources on usb_ep_queuefailure. This patch continues to use goto logic for error handling, as theexisting error handling is complex and not easily adaptable to auto-cleanuphelpers.kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: fix double free on late probe failureThe MOST subsystem has a non-standard registration function which freesthe interface on registration failures and on deregistration.This unsurprisingly leads to bugs in the MOST drivers, and a couple ofrecent changes turned a reference underflow and use-after-free in theUSB driver into several double free and a use-after-free on late probefailures.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: fix fragment overflow handling in RX pathThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)fragments when handling large multi-descriptor packets. This causes anout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.The issue occurs because the driver doesn't check the total number offragments before calling skb_add_rx_frag(). When a packet requires morethan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,then all fragments are accounted for. And reusing the existing check toprevent the overflow earlier in the code path.This crash occurred in production with an Aquantia AQC113 10G NIC.Stack trace from production environment:```RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 4889 fa 83RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:fffffffe0a0c8000RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:0000000000037a40RBP: 0000000000000024 R08: 0000000000000000 R09:0000000000000021R10: 0000000000000848 R11: 0000000000000000 R12:ffffa9bec02a8e24R13: ffff925ad8615570 R14: 0000000000000000 R15:ffff925b22e80a00FS: 0000000000000000(0000)GS:ffff925e47880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:0000000000f72ef0PKRU: 55555554Call Trace:aq_ring_rx_clean+0x175/0xe60 [atlantic]? aq_ring_rx_clean+0x14d/0xe60 [atlantic]? aq_ring_tx_clean+0xdf/0x190 [atlantic]? kmem_cache_free+0x348/0x450? aq_vec_poll+0x81/0x1d0 [atlantic]? __napi_poll+0x28/0x1c0? net_rx_action+0x337/0x420```Changes in v4:- Add Fixes: tag to satisfy patch validation requirements.Changes in v3:- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: leaf: Fix potential infinite loop in command parsersThe `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`functions contain logic to zero-length commands. These commands are usedto align data to the USB endpoint's wMaxPacketSize boundary.The driver attempts to skip these placeholders by aligning the bufferposition `pos` to the next packet boundary using `round_up()` function.However, if zero-length command is found exactly on a packet boundary(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`function will return the unchanged value of `pos`. This prevents `pos`to be increased, causing an infinite loop in the parsing logic.This patch fixes this in the function by using `pos + 1` instead.This ensures that even if `pos` is on a boundary, the calculation isbased on `pos + 1`, forcing `round_up()` to always return the nextaligned boundary.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:lan966x: Fix sleeping in atomic contextThe following warning was seen when we try to connect using ssh to the device.BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbearpreempt_count: 1, expected: 0INFO: lockdep is turned off.CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONETainted: [W]=WARNHardware name: Generic DT based systemCall trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1cException stack(0xf0b11fa8 to 0xf0b11ff0)1fa0: 00000001 00001000 00000008 be9048d8 00001000 000000011fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 000000011fe0: 0005404c be9048c0 00018684 b6ec2cd8It seems that we are using a mutex in a atomic context which is wrong.Change the mutex with a spinlock.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_cake: Fix incorrect qlen reduction in cake_dropIn cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlenand backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumesthat the parent qdisc will enqueue the current packet. However, thisassumption breaks when cake_enqueue() returns NET_XMIT_CN: the parentqdisc stops enqueuing current packet, leaving the tree qlen/backlogaccounting inconsistent. This mismatch can lead to a NULL dereference(e.g., when the parent Qdisc is qfq_qdisc).This patch computes the qlen/backlog delta in a more robust way byobserving the difference before and after the series of cake_drop()calls, and then compensates the qdisc tree accounting if cake_enqueue()returns NET_XMIT_CN.To ensure correct compensation when ACK thinning is enabled, a newvariable is introduced to keep qlen unchanged.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: c6xdigio: Fix invalid PNP driver unregistrationThe Comedi low-level driver "c6xdigio" seems to be for a parallel portconnected device. When the Comedi core calls the driver's Comedi"attach" handler `c6xdigio_attach()` to configure a Comedi to use thisdriver, it tries to enable the parallel port PNP resources byregistering a PNP driver with `pnp_register_driver()`, but ignores thereturn value. (The `struct pnp_driver` it uses has only the `name` and`id_table` members filled in.) The driver's Comedi "detach" handler`c6xdigio_detach()` unconditionally unregisters the PNP driver with`pnp_unregister_driver()`.It is possible for `c6xdigio_attach()` to return an error before itcalls `pnp_register_driver()` and it is possible for the call to`pnp_register_driver()` to return an error (that is ignored). In bothcases, the driver should not be calling `pnp_unregister_driver()` as itdoes in `c6xdigio_detach()`. (Note that `c6xdigio_detach()` will becalled by the Comedi core if `c6xdigio_attach()` returns an error, or ifthe Comedi core decides to detach the Comedi device from the driver forsome other reason.)The unconditional call to `pnp_unregister_driver()` without a previoussuccessful call to `pnp_register_driver()` will cause`driver_unregister()` to issue a warning "Unexpected driverunregister!". This was detected by Syzbot [1].Also, the PNP driver registration and unregistration should be done atmodule init and exit time, respectively, not when attaching or detachingComedi devices to the driver. (There might be more than one Comedidevice being attached to the driver, although that is unlikely.)Change the driver to do the PNP driver registration at module init time,and the unregistration at module exit time. Since `c6xdigio_detach()`now only calls `comedi_legacy_detach()`, remove the function and changethe Comedi driver "detach" handler to `comedi_legacy_detach`.-------------------------------------------[1] Syzbot sample crash report:Unexpected driver unregister!WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister drivers/base/driver.c:273 [inline]WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister+0x90/0xb0 drivers/base/driver.c:270Modules linked in:CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025RIP: 0010:driver_unregister drivers/base/driver.c:273 [inline]RIP: 0010:driver_unregister+0x90/0xb0 drivers/base/driver.c:270Code: 48 89 ef e8 c2 e6 82 fc 48 89 df e8 3a 93 ff ff 5b 5d e9 c3 6d d9 fb e8 be 6d d9 fb 90 48 c7 c7 e0 f8 1f 8c e8 51 a2 97 fb 90 <0f> 0b 90 90 5b 5d e9 a5 6d d9 fb e8 e0 f4 41 fc eb 94 e8 d9 f4 41RSP: 0018:ffffc9000373f9a0 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffffffff8ff24720 RCX: ffffffff817b6ee8RDX: ffff88807c932480 RSI: ffffffff817b6ef5 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8ff24660R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88814cca0000FS: 000055556dab1500(0000) GS:ffff8881249d9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055f77f285cd0 CR3: 000000007d871000 CR4: 00000000003526f0Call Trace: comedi_device_detach_locked+0x12f/0xa50 drivers/comedi/drivers.c:207 comedi_device_detach+0x67/0xb0 drivers/comedi/drivers.c:215 comedi_device_attach+0x43d/0x900 drivers/comedi/drivers.c:1011 do_devconfig_ioctl+0x1b1/0x710 drivers/comedi/comedi_fops.c:872 comedi_unlocked_ioctl+0x165d/0x2f00 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_sys---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems fromthe fact that in case of early device detach via pcl818_detach(),subdevice dev->read_subdev may not have initialized its pointer to&struct comedi_async as intended. Thus, any such dereferencing of&s->async->cmd will lead to general protection fault and kernel crash.Mitigate this problem by removing a call to pcl818_ai_cancel() frompcl818_detach() altogether. This way, if the subdevice setups itssupport for async commands, everything async-related will behandled via subdevice's own ->cancel() function incomedi_device_detach_locked() even before pcl818_detach(). If nosupport for asynchronous commands is provided, there is no needto cancel anything either.[1] Syzbot crash:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762...Call Trace: pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115 comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207 do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline] comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline]...
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: microchip: Don't free uninitialized ksz_irqIf something goes wrong at setup, ksz_irq_free() can be called onuninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). Itleads to freeing uninitialized IRQ numbers and/or domains.Use dsa_switch_for_each_user_port_continue_reverse() in the error pathto iterate only over the fully initialized ports.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()The acpi_get_first_physical_node() function can return NULL, in whichcase the get_device() function also returns NULL, but this value isthen dereferenced without checking,so add a check to prevent a crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: dice: fix buffer overflow in detect_stream_formats()The function detect_stream_formats() reads the stream_count value directlyfrom a FireWire device without validating it. This can lead toout-of-bounds writes when a malicious device provides a stream_count valuegreater than MAX_STREAMS.Fix by applying the same validation to both TX and RX stream counts indetect_stream_formats().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix refcount leak in exfat_findFix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.Function `exfat_get_dentry_set` would increase the reference counter of`es->bh` on success. Therefore, `exfat_put_dentry_set` must be calledafter `exfat_get_dentry_set` to ensure refcount consistency. This patchrelocate two checks to avoid possible leaks.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check skb->transport_header is set in bpf_skb_check_mtuThe bpf_skb_check_mtu helper needs to use skb->transport_header whenthe BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)The transport_header is not always set. There is a WARN_ON_ONCEreport when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +bpf_prog_test_run is used:WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skbFor a normal ingress skb (not test_run), skb_reset_transport_headeris performed but there is plan to avoid setting it as described incommit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").This patch fixes the bpf helper by checkingskb_transport_header_was_set(). The check is done just beforeskb->transport_header is used, to avoid breaking the existing bpf prog.The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Initialize allocated memory before useKMSAN reports: Multiple uninitialized values detected:- KMSAN: uninit-value in ntfs_read_hdr (3)- KMSAN: uninit-value in bcmp (3)Memory is allocated by __getname(), which is a wrapper forkmem_cache_alloc(). This memory is used before being properlycleared. Change kmem_cache_alloc() to kmem_cache_zalloc() toproperly allocate and clear memory before use.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix rcu protection in md_wakeup_threadWe attempted to use RCU to protect the pointer 'thread', but directlypassed the value when calling md_wakeup_thread(). This means that theRCU pointer has been acquired before rcu_read_lock(), which rendersrcu_read_lock() ineffective and could lead to a use-after-free.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check in __bpf_get_stackid()Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix peer HE MCS assignmentIn ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent tofirmware as receive MCS while peer's receive MCS sent as transmit MCS,which goes against firmwire's definition.While connecting to a misbehaved AP that advertises 0xffff (meaning notsupported) for 160 MHz transmit MCS map, firmware crashes due to 0xffffis assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffffSwap the assignment to fix this issue.As the HE rate control mask is meant to limit our own transmit MCS, itneeds to go via he_mcs->rx_mcs_set field. With the aforementioned swappingdone, change is needed as well to apply it to the peer's receive MCS.Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not let BPF test infra emit invalid GSO types to stackYinhao et al. reported that their fuzzer tool was able to trigger askb_warn_bad_offload() from netif_skb_features() -> gso_features_check().When a BPF program - triggered via BPF test infra - pushes the packetto the loopback device via bpf_clone_redirect() then mentioned offloadwarning can be seen. GSO-related features are then rightfully disabled.We get into this situation due to convert___skb_to_skb() settinggso_segs and gso_size but not gso_type. Technically, it makes sensethat this warning triggers since the GSO properties are malformed dueto the gso_type. Potentially, the gso_type could be marked non-trustworthythrough setting it at least to SKB_GSO_DODGY without any other specificassumptions, but that also feels wrong given we should not go furtherinto the GSO engine in the first place.The checks were added in 121d57af308d ("gso: validate gso_type in GSOhandlers") because there were malicious (syzbot) senders that combinea protocol with a non-matching gso_type. If we would want to drop suchpackets, gso_features_check() currently only returns feature flags vianetif_skb_features(), so one location for potentially dropping such skbscould be validate_xmit_unreadable_skb(), but then otoh it would bean additional check in the fast-path for a very corner case. Givenbpf_clone_redirect() is the only place where BPF test infra could emitsuch packets, lets reject them right there.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: Fix uninit buffer allocated by __getname()Fix uninit errors caused after buffer allocation given to 'de'; byinitializing the buffer with zeroes. The fix was found by using KMSAN.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: fix uninit memory after failed mi_read in mi_format_newFix a KMSAN un-init bug found by syzkaller.ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not beuptodate. We do not bring the buffer uptodate before setting it asuptodate. If the buffer were to not be uptodate, it could mean adding abuffer with un-init data to the mi record. Attempting to load that recordwill trigger KMSAN.Avoid this by setting the buffer as uptodate, if it's not already, byoverwriting it.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked whensetup_instance() fails with an error code. Fix that by freeing the urbbefore freeing the hw structure. Also change the error paths to use thegoto ladder style.Compile tested only. Issue found using a prototype static analysis tool.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-motu: add bounds check in put_user loop for DSP eventsIn the DSP event handling code, a put_user() loop copies event data.When the user buffer size is not aligned to 4 bytes, it could overwritebeyond the buffer boundary.Fix by adding a bounds check before put_user().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMAallocations in a loop. When an allocation fails, the previouslysuccessful allocations are not freed on exit.Fix that by jumping to err_free_rings label on error, which callsrtl8180_free_rx_ring() to free the allocations. Remove the free ofrx_ring in rtl8180_init_rx_ring() error path, and set the freedpriv->rx_buf entry to null, to avoid double free.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If thesubsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the functionreturns an error without freeing sskb, leading to a memory leak.Fix this by calling dev_kfree_skb() on sskb in the error handling pathto ensure it is properly released.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl-cpm: Check length parity before switching to 16 bit modeCommit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transferswith even size") failed to make sure that the size is really evenbefore switching to 16 bit mode. Until recently the problem wentunnoticed because kernfs uses a pre-allocated bounce buffer of sizePAGE_SIZE for reading EEPROM.But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API")introduced an additional dynamically allocated bounce buffer whose sizeis exactly the size of the transfer, leading to a buffer overrun inthe fsl-cpm driver when that size is odd.Add the missing length parity verification and remain in 8 bit modewhen the length is not even.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: initialize local pointers upon transfer of memory ownershipvidtv_channel_si_init() creates a temporary list (program, service, event)and ownership of the memory itself is transferred to the PAT/SDT/EITtables through vidtv_psi_pat_program_assign(),vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().The problem here is that the local pointer where the memory ownershiptransfer was completed is not initialized to NULL. This causes thevidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, andin the flow that jumps to free_eit, the memory that was freed byvidtv_psi_*_table_destroy() can be accessed again byvidtv_psi_*_event_destroy() due to the uninitialized local pointer, so itis freed once again.Therefore, to prevent use-after-free and double-free vulnerability,local pointers must be initialized to NULL when transferring memoryownership.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslotReject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that wasinitially created with a guest_memfd binding, as KVM doesn't supporttoggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enablingKVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.Failure to reject the new memslot results in a use-after-free due to KVMnot unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLYchange is easy enough, and can/will be done as a hardening measure (inanticipation of KVM supporting dirty logging on guest_memfd at some point),but fixing the use-after-free would only address the immediate symptom. ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745 CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5c0 kasan_report+0xb4/0xe0 kvm_gmem_release+0x362/0x400 [kvm] __fput+0x2fa/0x9d0 task_work_run+0x12c/0x200 do_exit+0x6ae/0x2100 do_group_exit+0xa8/0x230 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0x737/0x740 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 Allocated by task 745 on cpu 6 at 9.746971s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_kmalloc+0x77/0x90 kvm_set_memory_region.part.0+0x652/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 745 on cpu 6 at 9.747467s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x3b/0x60 kfree+0xf5/0x440 kvm_set_memslot+0x3c2/0x1160 [kvm] kvm_set_memory_region.part.0+0x86a/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix filename leak in __io_openat_prep() __io_openat_prep() allocates a struct filename using getname(). However,for the condition of the file being installed in the fixed file table aswell as having O_CLOEXEC flag set, the function returns early. At thatpoint, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,the memory for the newly allocated struct filename is not cleaned up,causing a memory leak.Fix this by setting the REQ_F_NEED_CLEANUP for the request just after thesuccessful getname() call, so that when the request is torn down, thefilename will be cleaned up, along with other resources needing cleanup.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Remove drr class from the active list if it changes to strictWhenever a user issues an ets qdisc change command, transforming adrr class into a strict one, the ets code isn't checking whether thatclass was in the active list and removing it. This means that, if auser changes a strict class (which was in the active list) back to a drrone, that class will be added twice to the active list [1].Doing so with the following commands:tc qdisc add dev lo root handle 1: ets bands 2 strict 1tc qdisc add dev lo parent 1:2 handle 20: \ tbf rate 8bit burst 100b latency 1stc filter add dev lo parent 1: basic classid 1:2ping -c1 -W0.01 -s 56 127.0.0.1tc qdisc change dev lo root handle 1: ets bands 2 strict 2tc qdisc change dev lo root handle 1: ets bands 2 strict 1ping -c1 -W0.01 -s 56 127.0.0.1Will trigger the following splat with list debug turned on:[ 59.279014][ T365] ------------[ cut here ]------------[ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.[ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220[ 59.280860][ T365] Modules linked in:[ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)[ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220[ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44...[ 59.288812][ T365] Call Trace:[ 59.289056][ T365] [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80[ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0[ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10[ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240[ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10[ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.292313][ T365] ? trace_contention_end+0xc8/0x110[ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0Fix this by always checking and removing an ets class from the active listwhen changing it to strict.[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Cap the number of PCR bankstpm2_get_pcr_allocation() does not cap any upper limit for the number ofbanks. Cap the limit to eight banks so that out of bounds values comingfrom external I/O cause on only limited harm.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s/slb: Fix SLB multihit issue during SLB preloadOn systems using the hash MMU, there is a software SLB preload cache thatmirrors the entries loaded into the hardware SLB buffer. This preloadcache is subject to periodic eviction - typically after every 256 contextswitches - to remove old entry.To optimize performance, the kernel skips switch_mmu_context() inswitch_mm_irqs_off() when the prev and next mm_struct are the same.However, on hash MMU systems, this can lead to inconsistencies betweenthe hardware SLB and the software preload cache.If an SLB entry for a process is evicted from the software cache on oneCPU, and the same process later runs on another CPU without executingswitch_mmu_context(), the hardware SLB may retain stale entries. If thekernel then attempts to reload that entry, it can trigger an SLBmulti-hit error.The following timeline shows how stale SLB entries are created and cancause a multi-hit error when a process moves between CPUs without aMMU context switch.CPU 0 CPU 1----- -----Process Pexec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */context_switchsched_migrate_task migrates process P to cpu-1Process swapper/0 context switch (to process P)(uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb becomes 0 here * and we evict an entry from * the preload cache with * preload_age(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switch_slb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preload_cache * (after eviction). */ load_elf_binary continues... setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task migrates process P to cpu-0context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * Since both prev and next mm struct are same we don't call * switch_mmu_context(). This will cause the HW SLB and SW preload * cache to go out of sync in preload_new_slb_context. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preload_new_slb_context(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */load_elf_binary cont---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix the crash issue for zero copy XDP_TX actionThere is a crash issue when running zero copy XDP_TX action, the crashlog is shown below.[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000[ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP[ 216.301694] Call trace:[ 216.304130] dcache_clean_poc+0x20/0x38 (P)[ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0[ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400[ 216.317701] __stmmac_xdp_run_prog+0x164/0x368[ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00[ 216.326576] __napi_poll+0x40/0x218[ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interruptFor XDP_TX action, the xdp_buff is converted to xdp_frame byxdp_convert_buff_to_frame(). The memory type of the resulting xdp_framedepends on the memory type of the xdp_buff. For page pool based xdp_buffit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copyXSK pool based xdp_buff it produces xdp_frame with memory typeMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check thememory type and always uses the page pool type, this leads to invalidmappings and causes the crash. Therefore, check the xdp_buff memory typein stmmac_xdp_xmit_back() to fix this issue.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (w83791d) Convert macros to functions to avoid TOCTOUThe macro FAN_FROM_REG evaluates its arguments multiple times. When usedin lockless contexts involving shared driver data, this leads toTime-of-Check to Time-of-Use (TOCTOU) race conditions, potentiallycausing divide-by-zero errors.Convert the macro to a static function. This guarantees that argumentsare evaluated only once (pass-by-value), preventing the raceconditions.Additionally, in store_fan_div, move the calculation of the minimumlimit inside the update lock. This ensures that the read-modify-writesequence operates on consistent data.Adhere to the principle of minimal changes by only converting macrosthat evaluate arguments multiple times and are used in locklesscontexts.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Avoid walking the Namespace if start_node is NULLAlthough commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespaceif it is not there") fixed the situation when both start_node andacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashedon Honor Magicbook 14 Pro [1].That happens due to the access to the member of parent_node inacpi_ns_get_next_node(). The NULL pointer dereference will alwayshappen, no matter whether or not the start_node is equal toACPI_ROOT_OBJECT, so move the check of start_node being NULLout of the if block.Unfortunately, all the attempts to contact Honor have failed, theyrefused to provide any technical support for Linux.The bad DSDT table's dump could be found on GitHub [2].DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025[ rjw: Subject adjustment, changelog edits ]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: avoid deadlock on fallback while reinjectingJakub reported an MPTCP deadlock at fallback time: WARNING: possible recursive locking detected 6.18.0-rc7-virtme #1 Not tainted -------------------------------------------- mptcp_connect/20858 is trying to acquire lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280 but task is already holding lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&msk->fallback_lock); lock(&msk->fallback_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by mptcp_connect/20858: #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0 #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0 #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 stack backtrace: CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full) Hardware name: Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0x6f/0xa0 print_deadlock_bug.cold+0xc0/0xcd validate_chain+0x2ff/0x5f0 __lock_acquire+0x34c/0x740 lock_acquire.part.0+0xbc/0x260 _raw_spin_lock_bh+0x38/0x50 __mptcp_try_fallback+0xd8/0x280 mptcp_sendmsg_frag+0x16c2/0x3050 __mptcp_retrans+0x421/0xaa0 mptcp_release_cb+0x5aa/0xa70 release_sock+0xab/0x1d0 mptcp_sendmsg+0xd5b/0x1bc0 sock_write_iter+0x281/0x4d0 new_sync_write+0x3c5/0x6f0 vfs_write+0x65e/0xbb0 ksys_write+0x17e/0x200 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fa5627cbc5e Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005 RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920 R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9cThe packet scheduler could attempt a reinjection after receiving anMP_FAIL and before the infinite map has been transmitted, causing adeadlock since MPTCP needs to do the reinjection atomically from WRTfallback.Address the issue explicitly avoiding the reinjection in the criticalscenario. Note that this is the only fallback critical section thatcould potentially send packets and hit the double-lock.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Discard Beacon frames to non-broadcast addressBeacon frames are required to be sent to the broadcast address, see IEEEStd 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frameshall be set to the broadcast address"). A unicast Beacon frame might beused as a targeted attack to get one of the associated STAs to dosomething (e.g., using CSA to move it to another channel). As such, itis better have strict filtering for this on the received side anddiscard all Beacon frames that are sent to an unexpected address.This is even more important for cases where beacon protection is used.The current implementation in mac80211 is correctly discarding unicastBeacon frames if the Protected Frame bit in the Frame Control field isset to 0. However, if that bit is set to 1, the logic used for checkingfor configured BIGTK(s) does not actually work. If the driver does nothave logic for dropping unicast Beacon frames with Protected Frame bit1, these frames would be accepted in mac80211 processing as valid Beaconframes even though they are not protected. This would allow beaconprotection to be bypassed. While the logic for checking beaconprotection could be extended to cover this corner case, a more genericcheck for discard all Beacon frames based on A1=unicast address coversthis without needing additional changes.Address all these issues by dropping received Beacon frames if they aresent to a non-broadcast address.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbufferInitialize the eb.vma array with values of 0 when the eb structure isfirst set up. In particular, this sets the eb->vma[i].vma pointers toNULL, simplifying cleanup and getting rid of the bug described below.During the execution of eb_lookup_vmas(), the eb->vma array issuccessively filled up with struct eb_vma objects. This process includescalling eb_add_vma(), which might fail; however, even in the event offailure, eb->vma[i].vma is set for the currently processed buffer.If eb_add_vma() fails, eb_lookup_vmas() returns with an error, whichprompts a call to eb_release_vmas() to clean up the mess. Sinceeb_lookup_vmas() might fail during processing any (possibly not first)buffer, eb_release_vmas() checks whether a buffer's vma is NULL to knowat what point did the lookup function fail.In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helperfunction eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma isset to NULL in case i915_gem_object_userptr_submit_init() fails; thecurrent one needs to be cleaned up by eb_release_vmas() at this point,so the next one is set. If eb_add_vma() fails, neither the current northe next vma is set to NULL, which is a source of a NULL deref bugdescribed in the issue linked in the Closes tag.When entering eb_lookup_vmas(), the vma pointers are set to the slabpoison value, instead of NULL. This doesn't matter for the actuallookup, since it gets overwritten anyway, however the eb_release_vmas()function only recognizes NULL as the stopping value, hence the pointersare being set to NULL as they go in case of intermediate failure. Thispatch changes the approach to filling them all with NULL at the startinstead, rather than handling that manually during failure.(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smc91x: fix broken irq-context in PREEMPT_RTWhen smc91x.c is built with PREEMPT_RT, the following splat occursin FVP_RevC:[ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000[ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106][ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work[ 13.062266] C** replaying previous printk message **[ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}[ 13.062353] Hardware name: , BIOS[ 13.062382] Workqueue: mld mld_ifc_work[ 13.062469] Call trace:[ 13.062494] show_stack+0x24/0x40 (C)[ 13.062602] __dump_stack+0x28/0x48[ 13.062710] dump_stack_lvl+0x7c/0xb0[ 13.062818] dump_stack+0x18/0x34[ 13.062926] process_scheduled_works+0x294/0x450[ 13.063043] worker_thread+0x260/0x3d8[ 13.063124] kthread+0x1c4/0x228[ 13.063235] ret_from_fork+0x10/0x20This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,but smc_special_unlock() does not restore IRQs on PREEMPT_RT.The reason is that smc_special_unlock() calls spin_unlock_irqrestore(),and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invokercu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero.To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: avoid invalid read in irdma_net_eventirdma_net_event() should not dereference anything from "neigh" (alias"ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.Other events come with different structures pointed to by "ptr" and theymay be smaller than struct neighbour.Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.The bug is mostly harmless, but it triggers KASAN on debug kernels: BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma] Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554 CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1 Hardware name: [...] Workqueue: events rt6_probe_deferred Call Trace: dump_stack_lvl+0x60/0xb0 print_address_description.constprop.0+0x2c/0x3f0 print_report+0xb4/0x270 kasan_report+0x92/0xc0 irdma_net_event+0x32e/0x3b0 [irdma] notifier_call_chain+0x9e/0x180 atomic_notifier_call_chain+0x5c/0x110 rt6_do_redirect+0xb91/0x1080 tcp_v6_err+0xe9b/0x13e0 icmpv6_notify+0x2b2/0x630 ndisc_redirect_rcv+0x328/0x530 icmpv6_rcv+0xc16/0x1360 ip6_protocol_deliver_rcu+0xb84/0x12e0 ip6_input_finish+0x117/0x240 ip6_input+0xc4/0x370 ipv6_rcv+0x420/0x7d0 __netif_receive_skb_one_core+0x118/0x1b0 process_backlog+0xd1/0x5d0 __napi_poll.constprop.0+0xa3/0x440 net_rx_action+0x78a/0xba0 handle_softirqs+0x2d4/0x9c0 do_softirq+0xad/0xe0
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()The variable mddev->private is first assigned to conf and then checked: conf = mddev->private; if (!conf) ...If conf is NULL, then mddev->private is also NULL. In this case,null-pointer dereferences can occur when calling raid5_quiesce(): raid5_quiesce(mddev, true); raid5_quiesce(mddev, false);since mddev->private is assigned to conf again in raid5_quiesce(), and confis dereferenced in several places, for example: conf->quiesce = 0; wake_up(&conf->wait_for_quiescent);To fix this issue, the function should unlock mddev and return beforeinvoking raid5_quiesce() when conf is NULL, following the existing patternin raid5_change_consistency_policy().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"This patch ensures that the RX ring size (rx_pending) is notset below the permitted length. This avoids UBSANshift-out-of-bounds errors when users passes small or zeroring sizes via ethtool -G.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: Add missing NULL pointer check for pingpong interfaceIt is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in asingle place the check is missing.Also use convenient locals instead of phys_enc->* where available.Patchwork: https://patchwork.freedesktop.org/patch/693860/
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/tilcdc: Fix removal actions in case of failed probeThe drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpersshould only be called when the device has been successfully registered.Currently, these functions are called unconditionally in tilcdc_fini(),which causes warnings during probe deferral scenarios.[ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68...[ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108[ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8[ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144[ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc][ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]Fix this by rewriting the failed probe cleanup path using the standardgoto error handling pattern, which ensures that cleanup functions areonly called on successfully initialized resources. Additionally, removethe now-unnecessary is_registered flag.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: disable recursive forward error correctionThere are two problems with the recursive correction:1. It may cause denial-of-service. In fec_read_bufs, there is a loop thathas 253 iterations. For each iteration, we may call verity_hash_for_blockrecursively. There is a limit of 4 nested recursions - that means thatthere may be at most 253^4 (4 billion) iterations. Red Hat QE teamactually created an image that pushes dm-verity to this limit - and thisimage just makes the udev-worker process get stuck in the 'D' state.2. It doesn't work. In fec_read_bufs we store data into the variable"fio->bufs", but fio bufs is shared between recursive invocations, if"verity_hash_for_block" invoked correction recursively, it wouldoverwrite partially filled fio->bufs.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: tegra-adma: Fix use-after-freeA use-after-free bug exists in the Tegra ADMA driver when audio streamsare terminated, particularly during XRUN conditions. The issue occurswhen the DMA buffer is freed by tegra_adma_terminate_all() before thevchan completion tasklet finishes accessing it.The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memorySince tasklets can execute at any time after being scheduled, there isno guarantee that the buffer will remain valid when vchan_complete()runs.Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors.Crash logs:[ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0[ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0[ 337.427562] Call trace:[ 337.427564] dump_backtrace+0x0/0x320[ 337.427571] show_stack+0x20/0x30[ 337.427575] dump_stack_lvl+0x68/0x84[ 337.427584] print_address_description.constprop.0+0x74/0x2b8[ 337.427590] kasan_report+0x1f4/0x210[ 337.427598] __asan_load8+0xa0/0xd0[ 337.427603] vchan_complete+0x124/0x3b0[ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0[ 337.427617] tasklet_action+0x30/0x40[ 337.427623] __do_softirq+0x1a0/0x5c4[ 337.427628] irq_exit+0x110/0x140[ 337.427633] handle_domain_irq+0xa4/0xe0[ 337.427640] gic_handle_irq+0x64/0x160[ 337.427644] call_on_irq_stack+0x20/0x4c[ 337.427649] do_interrupt_handler+0x7c/0x90[ 337.427654] el1_interrupt+0x30/0x80[ 337.427659] el1h_64_irq_handler+0x18/0x30[ 337.427663] el1h_64_irq+0x7c/0x80[ 337.427667] cpuidle_enter_state+0xe4/0x540[ 337.427674] cpuidle_enter+0x54/0x80[ 337.427679] do_idle+0x2e0/0x380[ 337.427685] cpu_startup_entry+0x2c/0x70[ 337.427690] rest_init+0x114/0x130[ 337.427695] arch_call_rest_init+0x18/0x24[ 337.427702] start_kernel+0x380/0x3b4[ 337.427706] __primary_switched+0xc0/0xc8
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: fix device leaks on compat bind and unbindMake sure to drop the reference taken when looking up the idxd device aspart of the compat bind and unbind sysfs interface.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:counter: interrupt-cnt: Drop IRQF_NO_THREAD flagAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, asCONFIG_PROVE_RAW_LOCK_NESTING warns:=============================[ BUG: Invalid wait context ]6.18.0-rc1+git... #1-----------------------------some-user-space-process/1251 is trying to lock:(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]other info that might help us debug this:context-{2:2}no locks held by some-user-space-process/....stack backtrace:CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPTCall trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq... and Sebastian correctly points out. Remove IRQF_NO_THREAD as analternative to switching to raw_spinlock_t, because the latter would limitall potential nested locks to raw_spinlock_t only.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always detect conflicting inodes when logging inode refsAfter rename exchanging (either with the rename exchange operation orregular renames in multiple non-atomic steps) two inodes and at leastone of them is a directory, we can end up with a log tree that containsonly of the inodes and after a power failure that can result in an attemptto delete the other inode when it should not because it was not deletedbefore the power failure. In some case that delete attempt fails whenthe target inode is a directory that contains a subvolume inside it, sincethe log replay code is not prepared to deal with directory entries thatpoint to root items (only inode items).1) We have directories "dir1" (inode A) and "dir2" (inode B) under the same parent directory;2) We have a file (inode C) under directory "dir1" (inode A);3) We have a subvolume inside directory "dir2" (inode B);4) All these inodes were persisted in a past transaction and we are currently at transaction N;5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N;6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B), so after the exchange "dir1" is inode B and "dir2" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N;7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()).8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction);9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87.---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix NULL dereference on root when tracing inode evictionWhen evicting an inode the first thing we do is to setup tracing for it,which implies fetching the root's id. But in btrfs_evict_inode() theroot might be NULL, as implied in the next check that we do inbtrfs_evict_inode().Hence, we either should set the ->root_objectid to 0 in case the root isNULL, or we move tracing setup after checking that the root is notNULL. Setting the rootid to 0 at least gives us the possibility to tracethis call even in the case when the root is NULL, so that's the solutiontaken here.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: stm32: dmamux: fix device leak on route allocationMake sure to drop the reference taken when looking up the DMA muxplatform device during route allocation.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sva: invalidate stale IOTLB entries for kernel address spaceIntroduce a new IOMMU interface to flush IOTLB paging cache entries forthe CPU kernel address space. This interface is invoked from the x86architecture code that manages combined user and kernel page tables,specifically before any kernel page table page is freed and reused.This addresses the main issue with vfree() which is a common occurrenceand can be triggered by unprivileged users. While this resolves theprimary problem, it doesn't address some extremely rare case related tomemory unplug of memory that was present as reserved memory at boot, whichcannot be triggered by unprivileged users. The discussion can be found atthe link below.Enable SVA on x86 architecture since the IOMMU can now receivenotification to flush the paging cache before freeing the CPU kernel pagetable pages.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: Sanitize syscall table indexing under speculationThe syscall number is a user-controlled value used to index into thesyscall table. Use array_index_nospec() to clamp this value after thebounds check to prevent speculative out-of-bounds access and subsequentdata leakage via cache side channels.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()Add proper locking in mmp_pdma_residue() to prevent use-after-free whenaccessing descriptor list and descriptor contents.The race occurs when multiple threads call tx_status() while the taskleton another CPU is freeing completed descriptors:CPU 0 CPU 1----- -----mmp_pdma_tx_status()mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF!This issue can be reproduced when running dmatest on the same channel withmultiple threads (threads_per_chan > 1).Fix by protecting the chain_running list iteration and descriptor accesswith the chan->desc_lock spinlock.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Avoid creating sub-groups asynchronouslyThe asynchronous creation of sub-groups by a delayed work could lead to aNULL pointer dereference when the driver directory is removed before thework completes.The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0Fix this issue by using configfs_add_default_group() API which does nothave the deadlock problem as configfs_register_group() and does not requirethe delayed work handler.[mani: slightly reworded the description and added stable list]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A flaw was found in NetworkManager. The NetworkManager package allows access to files that may belong to other users. NetworkManager allows non-root users to configure the system's network. The daemon runs with root privileges and can access files owned by users different from the one who added the connection.
Packages affected:
NetworkManager > 0-0 (version in image is 1.42.6-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix crash when adding interface under a lagCommit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag")fixed a similar issue in the lan966x driver caused by a NULL pointer dereference.The ocelot_set_aggr_pgids() function in the ocelot driver has similar logicand is susceptible to the same crash.This issue specifically affects the ocelot_vsc7514.c frontend, which leavesunused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected asit uses the DSA framework which registers all ports.Fix this by checking if the port pointer is valid before accessing it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: check that server is running in unlock_filesystemIf we are trying to unlock the filesystem via an administrativeinterface and nfsd isn't running, it crashes the server. Thishappens currently because nfsd4_revoke_states() access statestructures (eg., conf_id_hashtbl) that has been freed as a partof the server shutdown.[ 59.465072] Call trace:[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd][ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd][ 59.466780] vfs_write+0x1f0/0x938[ 59.467088] ksys_write+0xfc/0x1f8[ 59.467395] __arm64_sys_write+0x74/0xb8[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8[ 59.468177] do_el0_svc+0x154/0x1d8[ 59.468489] el0_svc+0x40/0xe0[ 59.468767] el0t_64_sync_handler+0xa0/0xe8[ 59.469138] el0t_64_sync+0x1ac/0x1b0Ensure this can't happen by taking the nfsd_mutex and checking thatthe server is still up, and then holding the mutex across the call tonfsd4_revoke_states().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make free_choose_arg_map() resilient to partial allocationfree_choose_arg_map() may dereference a NULL pointer if its caller failsafter a partial allocation.For example, in decode_choose_args(), if allocation of arg_map->argsfails, execution jumps to the fail label and free_choose_arg_map() iscalled. Since arg_map->size is updated to a non-zero value before memoryallocation, free_choose_arg_map() will iterate over arg_map->args anddereference a NULL pointer.To prevent this potential NULL pointer dereference and makefree_choose_arg_map() more resilient, add checks for pointers beforeiterating.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rtsSince j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() iscalled only when the timer is enabled, we need to callj1939_session_deactivate_activate_next() if we cancelled the timer.Otherwise, refcount for j1939_session leaks, which will later appear as| unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.problem.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovecCommit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")added ttag bounds checking and data_offsetvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validatewhether the command's data structures (cmd->req.sg and cmd->iov) havebeen properly initialized before processing H2C_DATA PDUs.The nvmet_tcp_build_pdu_iovec() function dereferences these pointerswithout NULL checks. This can be triggered by sending H2C_DATA PDUimmediately after the ICREQ/ICRESP handshake, beforesending a CONNECT command or NVMe write command.Attack vectors that trigger NULL pointer dereferences:1. H2C_DATA PDU sent before CONNECT -> both pointers NULL2. H2C_DATA PDU for READ command -> cmd->req.sg allocated, cmd->iov NULL3. H2C_DATA PDU for uninitialized command slot -> both pointers NULLThe fix validates both cmd->req.sg and cmd->iov before callingnvmet_tcp_build_pdu_iovec(). Both checks are required because:- Uninitialized commands: both NULL- READ commands: cmd->req.sg allocated, cmd->iov NULL- WRITE commands: both allocated
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix crash on profile change rollback failuremlx5e_netdev_change_profile can fail to attach a new profile and canfail to rollback to old profile, in such case, we could end up with adangling netdev with a fully reset netdev_priv. A retry to changeprofile, e.g. another attempt to call mlx5e_netdev_change_profile viaswitchdev mode change, will crash trying to access the now NULLpriv->mdev.This fix allows mlx5e_netdev_change_profile() to handle previousfailures and an empty priv, by not assuming priv is valid.Pass netdev and mdev to all flows requiringmlx5e_netdev_change_profile() and avoid passing priv.In mlx5e_netdev_change_profile() check if current priv is valid, and ifnot, just attach the new profile without trying to access the old one.This fixes the following oops, when enabling switchdev mode for the 2ndtime after first time failure: ## Enabling switchdev mode first time:mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offloadworkqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) ## retry: Enabling switchdev mode 2nd time:mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offloadBUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_detach_netdev+0x3c/0x90Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07RSP: 0018:ffffc90000673890 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0Call Trace: mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fdfb8495047
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: tlv320adcx140: fix null pointerThe "snd_soc_component" in "adcx140_priv" was only used once but neverset. It was only used for reaching "dev" which is already present in"adcx140_priv".
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_gre: make ipgre_header() robustAnalog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")Over the years, syzbot found many ways to crash the kernelin ipgre_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 ipgre device.[1]skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 !Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 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 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix error handling in the init_task on loadIf the init_task fails during a driver load, we end up without vports andnetdevs, effectively failing the entire process. In that state asubsequent reset will result in a crash as the service task attempts toaccess uninitialized resources. Following trace is from an error in theinit_task where the CREATE_VPORT (op 501) is rejected by the FW:[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)[40958.148190] idpf 0000:83:00.0: HW reset detected[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8...[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf][40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]...[40958.177932] Call Trace:[40958.178491] [40958.179040] process_one_work+0x226/0x6d0[40958.179609] worker_thread+0x19e/0x340[40958.180158] ? __pfx_worker_thread+0x10/0x10[40958.180702] kthread+0x10f/0x250[40958.181238] ? __pfx_kthread+0x10/0x10[40958.181774] ret_from_fork+0x251/0x2b0[40958.182307] ? __pfx_kthread+0x10/0x10[40958.182834] ret_from_fork_asm+0x1a/0x30[40958.183370] Fix the error handling in the init_task to make sure the service andmailbox tasks are disabled if the error happens during load. These arestarted in idpf_vc_core_init(), which spawns the init_task and has no wayof knowing if it failed. If the error happens on reset, followingsuccessful driver load, the tasks can still run, as that will allow thenetdevs to attempt recovery through another reset. Stop the PTP callbackseither way as those will be restarted by the call to idpf_vc_core_init()during a successful reset.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: 3com: 3c59x: fix possible null dereference in vortex_probe1()pdev can be null and free_ring: can be called in 1297 with a nullpdev.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make calc_target() set t->paused, not just clear itCurrently calc_target() clears t->paused if the request shouldn't bepaused anymore, but doesn't ever set t->paused even though it's able todetermine when the request should be paused. Setting t->paused is leftto __submit_request() which is fine for regular requests but doesn'twork for linger requests -- since __submit_request() doesn't operateon linger requests, there is nowhere for lreq->t.paused to be set.One consequence of this is that watches don't get reestablished onpaused -> unpaused transitions in cases where requests have been pausedlong enough for the (paused) unwatch request to time out and for thesubsequent (re)watch request to enter the paused state. On top of thewatch not getting reestablished, rbd_reregister_watch() gets stuck withrbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_waitIt's waiting for lreq->reg_commit_wait to be completed, but for that tohappen the respective request needs to end up on need_resend_linger listand be kicked when requests are unpaused. There is no chance for thatif the request in question is never marked paused in the first place.The fact that rbd_dev->watch_mutex remains taken out forever thenprevents the image from getting unmapped -- "rbd unmap" would inevitablyhang in D state on an attempt to grab the mutex.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In esd_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inesd_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in esd_usb_close().Fix the memory leak by anchoring the URB in theesd_usb_read_bulk_callback() to the dev->rx_submitted anchor.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Avoid truncating memory addressesOn 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmemallocations to be backed by addresses physical memory above the 32-bitaddress limit, as found while experimenting with larger VMSPLITconfigurations.This caused the qemu virt model to crash in the GICv3 driver, whichallocates the 'itt' object using GFP_KERNEL. Since all memory belowthe 4GB physical address limit is in ZONE_DMA in this configuration,kmalloc() defaults to higher addresses for ZONE_NORMAL, and theITS driver stores the physical address in a 32-bit 'unsigned long'variable.Change the itt_addr variable to the correct phys_addr_t type instead,along with all other variables in this driver that hold a physicaladdress.The gicv5 driver correctly uses u64 variables, while all other irqchipdrivers don't call virt_to_phys or similar interfaces. It's expected thatother device drivers have similar issues, but fixing this one issufficient for booting a virtio based guest.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()Memory allocated for struct vscsiblk_info in scsiback_probe() is notfreed in scsiback_remove() leading to potential memory leaks on remove,as well as in the scsiback_probe() error paths. Fix that by freeing itin scsiback_remove().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix crash on synthetic stacktrace field usageWhen creating a synthetic event based on an existing synthetic event thathad a stacktrace field and the new synthetic event used that field akernel crash occurred: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/triggerThe above creates a synthetic event that takes a stacktrace when a taskschedules out in a non-running state and passes that stacktrace to thesched_switch event when that task schedules back in. It triggers the"stack" synthetic event that has a stacktrace as its field (called "stack"). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/triggerThe above makes another synthetic event called "syscall_stack" thatattaches the first synthetic event (stack) to the sys_exit trace event andrecords the stacktrace from the stack event with the id of the system callthat is exiting.When enabling this event (or using it in a historgram): ~# echo 1 > events/synthetic/syscall_stack/enableProduces a kernel crash! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reason is that the stacktrace field is not labeled as such, and istreated as a normal field and not as a dynamic event that it is.In trace_event_raw_event_synth() the event is field is still treated as adynamic array, but the retrieval of the data is considered a normal field,and the reference is just the meta data:// Meta data is retrieved instead of a dynamic array---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: core: fix device reference leak on report presentSlimbus devices can be allocated dynamically upon reception ofreport-present messages.Make sure to drop the reference taken when looking up already registereddevices.Note that this requires taking an extra reference in case the device hasnot yet been registered and has to be allocated.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: smbd: fix dma_unmap_sg() nentsThe dma_unmap_sg() functions should be called with the same nents as thedma_map_sg(), not the value the map function returned.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:gue: Fix skb memleak with inner IP protocol 0.syzbot reported skb memleak below. [0]The repro generated a GUE packet with its inner protocol 0.gue_udp_recv() returns -guehdr->proto_ctype for "resubmit"in ip_protocol_deliver_rcu(), but this only works withnon-zero protocol number.Let's drop such packets.Note that 0 is a valid number (IPv6 Hop-by-Hop Option).I think it is not practical to encap HOPOPT in GUE, so oncesomeone starts to complain, we could pass down a resubmitflag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT[0]BUG: memory leakunreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:migrate: correct lock ordering for hugetlb file foliosSyzbot has found a deadlock (analyzed by Lance Yang):1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquirefolio_lock.migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)!hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock!The migration path is the one taking locks in the wrong order according tothe documentation at the top of mm/rmap.c. So expand the scope of theexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.This is (mostly) how it used to be after commit c0d0381ade79. That wasremoved by 336bf30eb765 for both file & anon hugetlb pages when it shouldonly have been removed for anon hugetlb pages.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Fix restoration of SVE contextWhen SME is supported, Restoring SVE signal context can go wrong in afew ways, including placing the task into an invalid state where thekernel may read from out-of-bounds memory (and may potentially take afatal fault) and/or may kill the task with a SIGKILL.(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time.(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length.Fix (1) by setting TIF_SME when setting SVCR.SM. This also requiresensuring that the task's sme_state has been allocated, but as this couldcontain live ZA state, it should not be zeroed. Fix (2) by clearingSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME,and fp_type earlier, immediately after the allocation ofsve_state/sme_state, before the restore of the actual register state.This makes it easier to ensure that these are always modifiedconsistently, even if a fault is taken while reading the register datafrom the signal context. I do not expect any software to depend on theexact state restored when a fault is taken while reading the context.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Make the addrs_lock be per portMake the addrs_lock be per port, not per ipvlan dev.Initial code seems to be written in the assumption,that any address change must occur under RTNL.But it is not so for the case of IPv6. So1) Introduce per-port addrs_lock.2) It was needed to fix places where it was forgottento take lock (ipvlan_open/ipvlan_close)This appears to be a very minor problem though.Since it's highly unlikely that ipvlan_add_addr() willbe called on 2 CPU simultaneously. But nevertheless,this could cause:1) False-negative of ipvlan_addr_busy(): one interfaceiterated through all port->ipvlans + ipvlan->addrsunder some ipvlan spinlock, and another added IPunder its own lock. Though this is only possiblefor IPv6, since looks like only ipvlan_addr6_event() can becalled without rtnl_lock.2) Race since ipvlan_ht_addr_add(port) is called underdifferent ipvlan->addrs_lock locksThis should not affect performance, since add/remove IPis a rare situation and spinlock is not taken on fastpaths.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Allocate SSVE storage when restoring ZAThe code to restore a ZA context doesn't attempt to allocate the task'ssve_state before setting TIF_SME. Consequently, restoring a ZA contextcan place a task into an invalid state where TIF_SME is set but thetask's sve_state is NULL.In legitimate but uncommon cases where the ZA signal context was NOTcreated by the kernel in the context of the same task (e.g. if the taskis saved/restored with something like CRIU), we have no guarantee thatsve_state had been allocated previously. In these cases, userspace canenter streaming mode without trapping while sve_state is NULL, causing alater NULL pointer dereference when the kernel attempts to store theregister state:| # ./sigreturn-za| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000| Mem abort info:| ESR = 0x0000000096000046| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x06: level 2 translation fault| Data abort info:| ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000| CM = 0, WnR = 1, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000| Internal error: Oops: 0000000096000046 [#1] SMP| Modules linked in:| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT| Hardware name: linux,dummy-virt (DT)| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)| pc : sve_save_state+0x4/0xf0| lr : fpsimd_save_user_state+0xb0/0x1c0| sp : ffff80008070bcc0| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440| Call trace:| sve_save_state+0x4/0xf0 (P)| fpsimd_thread_switch+0x48/0x198| __switch_to+0x20/0x1c0| __schedule+0x36c/0xce0| schedule+0x34/0x11c| exit_to_user_mode_loop+0x124/0x188| el0_interrupt+0xc8/0xd8| __el0_irq_handler_common+0x18/0x24| el0t_64_irq_handler+0x10/0x1c| el0t_64_irq+0x198/0x19c| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)| ---[ end trace 0000000000000000 ]---Fix this by having restore_za_context() ensure that the task's sve_stateis allocated, matching what we do when taking an SME trap. Any liveSVE/SSVE state (which is restored earlier from a separate signalcontext) must be preserved, and hence this is not zeroed.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loopCurrently this is checked before running the pending work. Normally thisis quite fine, as work items either end up blocking (which will create anew worker for other items), or they complete fairly quickly. But syzbotreports an issue where io-wq takes seemingly forever to exit, and with abit of debugging, this turns out to be because it queues a bunch of big(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn'tsupport ->read_iter(), loop_rw_iter() ends up handling them. Each readreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch ofthese pending, processing the whole chain can take a long time. Easilylonger than the syzbot uninterruptible sleep timeout of 140 seconds.This then triggers a complaint off the io-wq exit path:INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa02738f749RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000caRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98There's really nothing wrong here, outside of processing these readswill take a LONG time. However, we can speed up the exit by checking theIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot willexit the ring after queueing up all of these reads. Then once the firstitem is processed, io-wq will simply cancel the rest. That should avoidsyzbot running into this complaint again.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpuFor i.MX8MQ platform, the ADB in the VPUMIX domain has no separate resetand clock enable bits, but is ungated and reset together with the VPUs.So we can't reset G1 or G2 separately, it may led to the system hang.Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.Let imx8mq_vpu_power_notifier() do really vpu reset.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ice: add missing ice_deinit_hw() in devlink reinit pathdevlink-reload results in ice_init_hw failed error, and then removingthe ice driver causes a NULL pointer dereference.[ +0.102213] ice 0000:ca:00.0: ice_init_hw failed: -16...[ +0.000001] Call Trace:[ +0.000003] [ +0.000006] ice_unload+0x8f/0x100 [ice][ +0.000081] ice_remove+0xba/0x300 [ice]Commit 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() onerror paths") removed ice_deinit_hw() from ice_deinit_dev(). As a resultice_devlink_reinit_down() no longer calls ice_deinit_hw(), butice_devlink_reinit_up() still calls ice_init_hw(). Since the controlqueues are not uninitialized, ice_init_hw() fails with -EBUSY.Add ice_deinit_hw() to ice_devlink_reinit_down() to correspond withice_init_hw() in ice_devlink_reinit_up().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix data-race warning and potential load/store tearingFix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packetwhich is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds();and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;The lockless accesses to these to values aren't actually a problem as theread only needs an approximate time of last transmission for the purposesof deciding whether or not the transmission of a keepalive packet iswarranted yet.Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bitarch.Fix both of these by switching to an unsigned int for ->last_tx_at and onlystoring the LSW of the time64_t. It can then be reconstructed at needprovided no more than 68 years has elapsed since the last transmission.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: provide a net pointer to __skb_flow_dissect()After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")we have to provide a net pointer to __skb_flow_dissect(),either via skb->dev, skb->sk, or a user provided pointer.In the following case, syzbot was able to cook a bare skb.WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: avoid one data-race in l2tp_tunnel_del_work()We should read sk->sk_socket only when dealing with kernel sockets.syzbot reported the following data-race:BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_releasewrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246value changed: 0xffff88811b818000 -> 0x0000000000000000
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: annotate data-race in ndisc_router_discovery()syzbot found that ndisc_router_discovery() could read and writein6_dev->ra_mtu without holding a lock [1]This looks fine, IFLA_INET6_RA_MTU is best effort.Add READ_ONCE()/WRITE_ONCE() to document the race.Note that we might also reject illegal MTU values(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.[1]BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discoveryread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...value changed: 0x00000000 -> 0xe5400659
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INITA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH keyinitialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127The issue is triggered when sctp_auth_asoc_init_active_key() fails insctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, thecommand sequence is currently:- SCTP_CMD_PEER_INIT- SCTP_CMD_TIMER_STOP (T1_INIT)- SCTP_CMD_TIMER_START (T1_COOKIE)- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)- SCTP_CMD_ASSOC_SHKEY- SCTP_CMD_GEN_COOKIE_ECHOIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, whileasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set bySCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULLto be queued by sctp_datamsg_from_user().Since command interpretation stops on failure, no COOKIE_ECHO should beensent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has alreadybeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. Asa result, the DATA chunk can be transmitted together with the COOKIE_ECHOin sctp_outq_flush_data(), leading to the observed issue.Similar to the other places where it calls sctp_auth_asoc_init_active_key()right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEYimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and startingT1_COOKIE. This ensures that if shared key generation fails, authenticatedDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,giving the client another chance to process INIT_ACK and retry key setup.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: reset sparse-read state in osd_fault()When a fault occurs, the connection is abandoned, reestablished, and anypending operations are retried. The OSD client tracks the progress of asparse-read reply using a separate state machine, largely independent ofthe messenger's state.If a connection is lost mid-payload or the sparse-read state machinereturns an error, the sparse-read state is not reset. The OSD clientwill then interpret the beginning of a new reply as the continuation ofthe old one. If this makes the sparse-read machinery enter a failurestate, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on readTherefore, reset the sparse-read state in osd_fault(), ensuring retriesstart from a clean state.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add recursion protection in kernel stack trace recordingA bug was reported about an infinite recursion caused by tracing the rcuevents with the kernel stack trace trigger enabled. The stack trace codecalled back into RCU which then called the stack trace again.Expand the ftrace recursion protection to add a set of bits to protectevents from recursion. Each bit represents the context that the event isin (normal, softirq, interrupt and NMI).Have the stack trace code use the interrupt context to protect againstrecursion.Note, the bug showed an issue in both the RCU code as well as the tracingstacktrace code. This only handles the tracing stack trace side of thebug. The RCU fix will be handled separately.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: update last_gc only when GC has been performedCurrently last_gc is being updated everytime a new connection istracked, that means that it is updated even if a GC wasn't performed.With a sufficiently high packet rate, it is possible to always bypassthe GC, causing the list to grow infinitely.Update the last_gc value only when a GC has been actually performed.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Subtract size of xdp_frame from allowed metadata sizeThe xdp_frame structure takes up part of the XDP frame headroom,limiting the size of the metadata. However, in bpf_test_run, we don'ttake this into account, which makes it possible for userspace to supplya metadata size that is too large (taking up the entire headroom).If userspace supplies such a large metadata size in live packet mode,the xdp_update_frame_from_buff() call in xdp_test_run_init_page() callwill fail, after which packet transmission proceeds with anuninitialised frame structure, leading to the usual Bad Stuff.The commit in the Fixes tag fixed a related bug where the second checkin xdp_update_frame_from_buff() could fail, but did not add anyadditional constraints on the metadata size. Complete the fix by addingan additional check on the metadata size. Reorder the checks slightly tomake the logic clearer and add a comment.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: send: check for inline extents in range_is_hole_in_parent()Before accessing the disk_bytenr field of a file extent item we needto check if we are dealing with an inline extent.This is because for inline extents their data starts at the offset ofthe disk_bytenr field. So accessing the disk_bytenrmeans we are accessing inline data or in case the inline data is lessthan 8 bytes we can actually cause an invalidmemory access if this inline extent item is the first item in the leafor access metadata from other items.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failureWhen a DAMOS-scheme DAMON sysfs directory setup fails after setup ofaccess_pattern/ directory, subdirectories of access_pattern/ directory arenot cleaned up. As a result, DAMON sysfs interface is nearly broken untilthe system reboots, and the memory for the unremoved directory is leaked.Cleanup the directories under such failures.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: cleanup attrs subdirs on context dir setup failureWhen a context DAMON sysfs directory setup is failed after setup of attrs/directory, subdirectories of attrs/ directory are not cleaned up. As aresult, DAMON sysfs interface is nearly broken until the system reboots,and the memory for the unremoved directory is leaked.Cleanup the directories under such failures.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix segmentation of forwarding fraglist GROThis patch enhances GSO segment handling by properly checkingthe SKB_GSO_DODGY flag for frag_list GSO packets, addressinglow throughput issues observed when a station accesses IPv4servers via hotspots with an IPv6-only upstream interface.Specifically, it fixes a bug in GSO segmentation when forwardingGRO packets containing a frag_list. The function skb_segment_listcannot correctly process GRO skbs that have been converted by XLAT,since XLAT only translates the header of the head skb. Consequently,skbs in the frag_list may remain untranslated, resulting in protocolinconsistencies and reduced throughput.To address this, the patch explicitly sets the SKB_GSO_DODGY flagfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSOpackets as potentially modified after protocol translation. As aresult, GSO segmentation will avoid using skb_segment_list andinstead falls back to skb_segment for packets with the SKB_GSO_DODGYflag. This ensures that only safe and fully translated frag_listpackets are processed by skb_segment_list, resolving protocolinconsistencies and improving throughput when forwarding GRO packetsconverted by XLAT.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not strictly require dirty metadata threshold for metadata writepages[BUG]There is an internal report that over 1000 processes arewaiting at the io_schedule_timeout() of balance_dirty_pages(), causinga system hang and trigger a kernel coredump.The kernel is v6.4 kernel based, but the root problem still applies toany upstream kernel before v6.18.[CAUSE]From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup.So that means the only way to reduce the dirty pages of that cgroup isto writeback the dirty pages of btrfs btree inode, and only after thatthose processes can exit balance_dirty_pages().Now back to the btrfs part, btree_writepages() is responsible forwriting back dirty btree inode pages.The problem here is, there is a btrfs internal threshold that if thebtree inode's dirty bytes are below the 32M threshold, it will notdo any writeback.This behavior is to batch as much metadata as possible so we won't writeback those tree blocks and then later re-COW them again for anothermodification.This internal 32MiB is higher than the existing dirty page size (28MiB),meaning no writeback will happen, causing a deadlock between btrfs andcgroup:- Btrfs doesn't want to write back btree inode until more dirty pages- Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced.Thanks Jan Kara a lot for the analysis of the root cause.[ENHANCEMENT]Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on thebtree_inode"), btrfs btree inode pages will only be charged to the rootcgroup which should have a much larger limit than btrfs' 32MiBthreshold.So it should not affect newer kernels.But for all current LTS kernels, they are all affected by this problem,and backporting the whole AS_KERNEL_FILE may not be a good idea.Even for newer kernels I still think it's a good idea to getrid of the internal threshold at btree_writepages(), since for most casescgroup/MM has a better view of full system memory usage than btrfs' fixedthreshold.For internal callers using btrfs_btree_balance_dirty() since thatfunction is already doing internal threshold check, we don't need tobother them.But for external callers of btree_writepages(), just respect theirrequests and write back whatever they want, ignoring the internalbtrfs threshold to avoid such deadlock on btree inode dirty pagebalancing.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:perf: sched: Fix perf crash with new is_user_task() helperIn order to do a user space stacktrace the current task needs to be a usertask that has executed in user space. It use to be possible to test if atask is a user task or not by simply checking the task_struct mm field. Ifit was non NULL, it was a user task and if not it was a kernel task.But things have changed over time, and some kernel tasks now have theirown mm field.An idea was made to instead test PF_KTHREAD and two functions were used towrap this check in case it became more complex to test if a task was auser task or not[1]. But this was rejected and the C code simply checkedthe PF_KTHREAD directly.It was later found that not all kernel threads set PF_KTHREAD. The io-uringhelpers instead set PF_USER_WORKER and this needed to be added as well.But checking the flags is still not enough. There's a very small windowwhen a task exits that it frees its mm field and it is set back to NULL.If perf were to trigger at this moment, the flags test would say its auser space task but when perf would read the mm field it would crash withat NULL pointer dereference.Now there are flags that can be used to test if a task is exiting, butthey are set in areas that perf may still want to profile the user spacetask (to see where it exited). The only real test is to check both theflags and the mm field.Instead of making this modification in every location, create a newis_user_task() helper function that does all the tests needed to know ifit is safe to read the user space memory or not.[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Fix memory leak in octep_device_setup()In octep_device_setup(), if octep_ctrl_net_init() fails, the functionreturns directly without unmapping the mapped resources and freeing theallocated configuration memory.Fix this by jumping to the unsupported_dev label, which performs thenecessary cleanup. This aligns with the error handling logic of otherpaths in this function.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:rocker: fix memory leak in rocker_world_port_post_fini()In rocker_world_port_pre_init(), rocker_port->wpriv is allocated withkzalloc(wops->port_priv_size, GFP_KERNEL). However, inrocker_world_port_post_fini(), the memory is only freed whenwops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);Since rocker_ofdpa_ops does not implement port_post_fini callback(it is NULL), the wpriv memory allocated for each port is never freedwhen ports are removed. This leads to a memory leak ofsizeof(struct ofdpa_port) bytes per port on every device removal.Fix this by always calling kfree(rocker_port->wpriv) regardless ofwhether the port_post_fini callback exists.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix deadlock in RSS config readSince cited commit, core locks the net_device's rss_lock when handling ethtool -x command, so driver's implementation should not lock it again. Remove the latter.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:flex_proportions: make fprop_new_period() hardirq safeBernd has reported a lockdep splat from flexible proportions code that isessentially complaining about the following race:run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - sees odd sequence so loops indefinitelyNote that a deadlock like this is only possible if the bdi has configuredmaximum fraction of writeout throughput which is very rare in general butfrequent for example for FUSE bdis. To fix this problem we have to makesure write section of the sequence counter is irqsafe.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()When the socket is closed while in TCP_LISTEN a callback is run toflush all outstanding packets, which in turns callsnvmet_tcp_listen_data_ready() with the sk_callback_lock held.So we need to check if we are in TCP_LISTEN before attemptingto get the sk_callback_lock() to avoid a deadlock.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domainsFix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix oops due to invalid pointer for kfree() in parse_longname()This fixes a kernel oops when reading ceph snapshot directories (.snap),for example by simply running `ls /mnt/my_ceph/.snap`.The variable str is guarded by __free(kfree), but advanced by one forskipping the initial '_' in snapshot names. Thus, kfree() is calledwith an invalid pointer. This patch removes the need for advancing thepointer so kfree() is called with correct memory pointer.Steps to reproduce:1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)2. Add cephfs mount to fstab$ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" >> /etc/fstab3. Reboot the system$ systemctl reboot4. Check if it's really mounted$ mount | grep stuff5. List snapshots (expected 63 snapshots on my system)$ ls /mnt/test/stuff/.snapNow ls hangs forever and the kernel log shows the oops.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: annotate data-races around slave->last_rxslave->last_rx and slave->target_last_arp_rx[...] can be read and writtenlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.syzbot reported:BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validatewrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410...write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline]...value changed: 0x0000000100005365 -> 0x0000000100005366
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Disable MMIO access during SMU Mode 1 resetDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomestemporarily inaccessible via PCIe. Any attempt to access MMIO registersduring this window (e.g., from interrupt handlers or other driver threads)can result in uncompleted PCIe transactions, leading to NMI panics orsystem hangs.To prevent this, set the `no_hw_access` flag to true immediately aftertriggering the reset. This signals other driver components to skipregister accesses while the device is offline.A memory barrier `smp_mb()` is added to ensure the flag update isglobally visible to all cores before the driver enters the sleep/waitstate.(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject new transactions if the fs is fully read-only[BUG]There is a bug report where a heavily fuzzed fs is mounted with allrescue mount options, which leads to the following warnings duringunmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Since rescue mount options will mark the full fs read-only, there shouldbe no new transaction triggered.But during unmount we will evict all inodes, which can trigger a newtransaction, and triggers warnings on a heavily corrupted fs.[CAUSE]Btrfs allows new transaction even on a read-only fs, this is to allowlog replay happen even on read-only mounts, just like what ext4/xfs do.However with rescue mount options, the fs is fully read-only and cannotbe remounted read-write, thus in that case we should also reject any newtransactions.[FIX]If we find the fs has rescue mount options, we should treat the fs aserror, so that no new transaction can be started.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmware: Fix hypercall clobbersFedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ...because the QEMU VMware mouse emulation is buggy, and clears the top 32bits of %rdi that the kernel kept a pointer in.The QEMU vmmouse driver saves and restores the register state in a"uint32_t data[6];" and as a result restores the state with the highbits all cleared.RDI originally contained the value of a valid kernel stack address(0xff5eeb3240003e54). After the vmware hypercall it now contains0x40003e54, and we get a page fault as a result when it is dereferenced.The proper fix would be in QEMU, but this works around the issue in thekernel to keep old setups working, when old kernels had not happened tokeep any state in %rdi over the hypercall.In theory this same issue exists for all the hypercalls in the vmmousedriver; in practice it has only been seen with vmware_hypercall3() andvmware_hypercall4(). For now, just mark RDI/RSI as clobbered for thosetwo calls. This should have a minimal effect on code generation overallas it should be rare for the compiler to want to make RDI/RSI liveacross hypercalls.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()In iscsit_dec_conn_usage_count(), the function calls complete() whileholding the conn->conn_usage_lock. As soon as complete() is invoked, thewaiter (such as iscsit_close_connection()) may wake up and proceed to freethe iscsit_conn structure.If the waiter frees the memory before the current thread reachesspin_unlock_bh(), it results in a KASAN slab-use-after-free as the functionattempts to release a lock within the already-freed connection structure.Fix this by releasing the spinlock before calling complete().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: add chann_lock to protect ksmbd_chann_list xarrayksmbd_chann_list xarray lacks synchronization, allowing use-after-free inmulti-channel sessions (between lookup_chann_list() and ksmbd_chann_del).Adds rw_semaphore chann_lock to struct ksmbd_session and protectsall xa_load/xa_store/xa_erase accesses.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).
Packages affected:
libgnutls30 > 0-0 (version in image is 3.8.3-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: bitblit: bound-check glyph index in bit_putcs*bit_putcs_aligned()/unaligned() derived the glyph pointer from thecharacter value masked by 0xff/0x1ff, which may exceed the actual font'sglyph count and read past the end of the built-in font array.Clamp the index to the actual glyph count before computing the address.This fixes a global out-of-bounds read reported by syzbot.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)
Packages affected:
openssh > 0-0 (version in image is 9.6p1-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Issue summary: A TLS 1.3 connection using certificate compression can beforced to allocate a large buffer before decompression without checkingagainst the configured certificate size limit.Impact summary: An attacker can cause per-connection memory allocations ofup to approximately 22 MiB and extra CPU work, potentially leading toservice degradation or resource exhaustion (Denial of Service).In affected configurations, the peer-supplied uncompressed certificatelength from a CompressedCertificate message is used to grow a heap bufferprior to decompression. This length is not bounded by the max_cert_listsetting, which otherwise constrains certificate message sizes. An attackercan exploit this to cause large per-connection allocations followed byhandshake failure. No memory corruption or information disclosure occurs.This issue only affects builds where TLS 1.3 certificate compression iscompiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compressionalgorithm (brotli, zlib, or zstd) is available, and where the compressionextension is negotiated. Both clients receiving a server CompressedCertificateand servers in mutual TLS scenarios receiving a client CompressedCertificateare affected. Servers that do not request client certificates are notvulnerable to client-initiated attacks.Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSIONto disable receiving compressed certificates.The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,as the TLS implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
Packages affected:
libopenssl3 > 0-0 (version in image is 3.1.4-slfo.1.1_8.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBsThe driver lacks the cleanup of failed transfers of URBs. This reduces thenumber of available URBs per error by 1. This leads to reduced performanceand ultimately to a complete stop of the transmission.If the sending of a bulk URB fails do proper cleanup:- increase netdev stats- mark the echo_sbk as free- free the driver's context and do accounting- wake the send queue
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:md: suspend array while updating raid_disks via sysfsIn raid1_reshape(), freeze_array() is called before modifying the r1biomemory pool (conf->r1bio_pool) and conf->raid_disks, andunfreeze_array() is called after the update is completed.However, freeze_array() only waits until nr_sync_pending and(nr_pending - nr_queued) of all buckets reaches zero. When an I/O erroroccurs, nr_queued is increased and the corresponding r1bio is queued toeither retry_list or bio_end_io_list. As a result, freeze_array() mayunblock before these r1bios are released.This can lead to a situation where conf->raid_disks and the mempool havealready been updated while queued r1bios, allocated with the oldraid_disks value, are later released. Consequently, free_r1bio() mayaccess memory out of bounds in put_all_bios() and release r1bios of thewrong size to the new mempool, potentially causing issues with themempool as well.Since only normal I/O might increase nr_queued while an I/O error occurs,suspending the array avoids this issue.Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspendsthe array. Therefore, we suspend the array when updating raid_disksvia sysfs to avoid this issue too.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
libxml2-2 > 0-0 (version in image is 2.11.6-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix memory leak in skb_segment_list for GRO packetsWhen skb_segment_list() is called during packet forwarding, it handlespackets that were aggregated by the GRO engine.Historically, the segmentation logic in skb_segment_list assumes thatindividual segments are split from a parent SKB and may need to carrytheir own socket memory accounting. Accordingly, the code transferstruesize from the parent to the newly created segments.Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), thistruesize subtraction in skb_segment_list() was valid because fragmentsstill carry a reference to the original socket.However, commit ed4cccef64c1 ("gro: fix ownership transfer") changedthis behavior by ensuring that fraglist entries are explicitlyorphaned (skb->sk = NULL) to prevent illegal orphaning later in thestack. This change meant that the entire socket memory charge remainedwith the head SKB, but the corresponding accounting logic inskb_segment_list() was never updated.As a result, the current code unconditionally adds each fragment'struesize to delta_truesize and subtracts it from the parent SKB. Sincethe fragments are no longer charged to the socket, this subtractionresults in an effective under-count of memory when the head is freed.This causes sk_wmem_alloc to remain non-zero, preventing socketdestruction and leading to a persistent memory leak.The leak can be observed via KMEMLEAK when tearing down the networkingenvironment:unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLISTpackets constructed by GRO, the truesize adjustment is removed.The call to skb_release_head_state() must be preserved. As documented incommit cf673ed0e057 ("net: fix fraglist segmentation reference countleak"), it is still required to correctly drop references to SKBextensions that may be overwritten during __copy_skb_header().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Sanitize payload size to prevent member overflowIn qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_sizereported by firmware is used to calculate the copy length intoitem->iocb. However, the iocb member is defined as a fixed-size 64-bytearray within struct purex_item.If the reported frame_size exceeds 64 bytes, subsequent memcpy calls willoverflow the iocb member boundary. While extra memory might be allocated,this cross-member write is unsafe and triggers warnings underCONFIG_FORTIFY_SOURCE.Fix this by capping total_bytes to the size of the iocb member (64 bytes)before allocation and copying. This ensures all copies remain within thebounds of the destination structure member.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix use-after-free due to enslave fail after slave array updateFix a use-after-free which happens due to enslave failure after the newslave has been added to the array. Since the new slave can be used for Tximmediately, we can use it after it has been freed by the enslave errorcleanup path which frees the allocated slave memory. Slave update array issupposed to be called last when further enslave failures are not expected.Move it after xdp setup to avoid any problems.It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummyThen run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? __pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix use-after-free in driver_override_show()The driver_override_show() function reads the driver_override stringwithout holding the device_lock. However, driver_override_store() usesdriver_set_override(), which modifies and frees the string while holdingthe device_lock.This can result in a concurrent use-after-free if the string is freedby the store function while being read by the show function.Fix this by holding the device_lock around the read operation.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.
Packages affected:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
libfreetype6 > 0-0 (version in image is 2.13.3-slfo.1.1_1.1).
Description: zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.
Packages affected:
libz1 > 0-0 (version in image is 1.2.13-slfo.1.1_1.3).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc: fix uaf in proc_readdir_de()Pde is erased from subdir rbtree through rb_erase(), but not set the nodeto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()set the erased node to EMPTY, then pde_subdir_next() will return NULL toavoid uaf access.We found an uaf issue while using stress-ng testing, need to run testcasegetdent and tun in the same time. The steps of the issue is as follows:1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.CPU 0 | CPU 1-------------------------------------------------------------------------traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Do not share the name pointer between componentsBy sharing 'name' directly, tearing down components may lead touse-after-free errors. Duplicate the name to avoid that.At the same time, update the order of operations - since commitcee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name viaconfig") the framework does not override component->name if set beforeinvoking the initializer.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix devlink reload call traceCommit 4da71a77fc3b ("ice: read internal temperature sensor") introducedinternal temperature sensor reading via HWMON. ice_hwmon_init() was addedto ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As aresult if devlink reload is used to reinit the device and then the driveris removed, a call trace can occur.BUG: unable to handle page fault for address: ffffffffc0fd4b5dCall Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60The call trace repeats approximately every 10 minutes when systemmonitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfsattributes that reference freed module memory.The sequence is:1. Driver load, ice_hwmon_init() gets called from ice_init_feature()2. Devlink reload down, flow does not call ice_remove()3. Devlink reload up, ice_hwmon_init() gets called from ice_init_feature() resulting in a second instance4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the first hwmon instance orphaned with dangling pointerFix this by moving ice_hwmon_exit() from ice_remove() toice_deinit_features() to ensure proper cleanup symmetry withice_hwmon_init().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: An issue was discovered in hyper v0.13.7. h2-0.2.4 Stream stacking occurs when the H2 component processes HTTP2 RST_STREAM frames. As a result, the memory and CPU usage are high which can lead to a Denial of Service (DoS).
Packages affected:
netavark > 0-0 (version in image is 1.12.2-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: kill hooked chains to avoid loops on deduplicated compressed imagesAfter heavily stressing EROFS with several images which include ahand-crafted image of repeated patterns for more than 46 days, I foundtwo chains could be linked with each other almost simultaneously andform a loop so that the entire loop won't be submitted. As aconsequence, the corresponding file pages will remain locked forever.It can be _only_ observed on data-deduplicated compressed images.For example, consider two chains with five pclusters in total: Chain 1: 2->3->4->5 -- The tail pcluster is 5; Chain 2: 5->1->2 -- The tail pcluster is 2.Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could linkto Chain 2 at the same time with pcluster 2.Since hooked chains are all linked locklessly now, I have no idea howto simply avoid the race. Instead, let's avoid hooked chains completelyuntil I could work out a proper way to fix this and end users finallytell us that it's needed to add it back.Actually, this optimization can be found with multi-threaded workloads(especially even more often on deduplicated compressed images), yet I'mnot sure about the overall system impacts of not having this comparedwith implementation complexity.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix locking for runpm vs reclaimFor cases where icc_bw_set() can be called in callbaths that coulddeadlock against shrinker/reclaim, such as runpm resume, we need todecouple the icc locking. Introduce a new icc_bw_lock for cases wherewe need to serialize bw aggregation and update to decouple that frompaths that require memory allocation such as node/link creation/destruction.Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix potential data race at PCM memory allocation helpersThe PCM memory allocation helpers have a sanity check against too manybuffer allocations. However, the check is performed without a properlock and the allocation isn't serialized; this allows user to allocatemore memories than predefined max size.Practically seen, this isn't really a big problem, as it's more orless some "soft limit" as a sanity check, and it's not possible toallocate unlimitedly. But it's still better to address this for moreconsistent behavior.The patch covers the size check in do_alloc_pages() with thecard->memory_mutex, and increases the allocated size there forpreventing the further overflow. When the actual allocation fails,the size is decreased accordingly.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nfp: clean mc addresses in application firmware when closing portWhen moving devices from one namespace to another, mc addresses arecleaned in software while not removed from application firmware. Thusthe mc addresses are remained and will cause resource leak.Now use `__dev_mc_unsync` to clean mc addresses when closing port.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sprd: Fix DMA buffer leak issueRelease DMA buffer when _probe() returns failure to avoid memory leak.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init()If we encounter any error in the vdec_msg_queue_init() then we needto set "msg_queue->wdma_addr.size = 0;". Normally, this is doneinside the vdec_msg_queue_deinit() function. However, if thefirst call to allocate &msg_queue->wdma_addr fails, then thevdec_msg_queue_deinit() function is a no-op. For that situation, justset the size to zero explicitly and return.There were two other error paths which did not clean up before returning.Change those error paths to goto mem_alloc_err.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link()If fwnode_graph_get_remote_endpoint() fails, 'fwnode' is known to be NULL,so fwnode_handle_put() is a no-op.Release the reference taken from a previous fwnode_graph_get_port_parent()call instead.Also handle fwnode_graph_get_port_parent() failures.In order to fix these issues, add an error handling path to the functionand the needed gotos.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:block: fix blktrace debugfs entries leakageCommit 99d055b4fd4b ("block: remove per-disk debugfs files inblk_unregister_queue") moves blk_trace_shutdown() fromblk_release_queue() to blk_unregister_queue(), this is safe if blktraceis created through sysfs, however, there is a regression in cornercase.blktrace can still be enabled after del_gendisk() through ioctl ifthe disk is opened before del_gendisk(), and if blktrace is not shutdownthrough ioctl before closing the disk, debugfs entries will be leaked.Fix this problem by shutdown blktrace in disk_release(), this is safebecause blk_trace_remove() is reentrant.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs()Free the cpumask allocated by create_affinity_masks() before returningfrom the function.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix lockdep splat and potential deadlock after failure running delayed itemsWhen running delayed items we are holding a delayed node's mutex and thenwe will attempt to modify a subvolume btree to insert/update/delete thedelayed items. However if have an error during the insertions for example,btrfs_insert_delayed_items() may return with a path that has locked extentbuffers (a leaf at the very least), and then we attempt to release thedelayed node at __btrfs_run_delayed_items(), which requires taking thedelayed node's mutex, causing an ABBA type of deadlock. This was reportedby syzbot and the lockdep splat is the following: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted ------------------------------------------------------ syz-executor.2/13257 is trying to acquire lock: ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: __lock_release kernel/locking/lockdep.c:5475 [inline] lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline] btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239 search_leaf fs/btrfs/ctree.c:1986 [inline] btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline] btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline] __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flush_space+0x269/0xe70 fs/btrfs/space-info.c:723 btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 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/0xcd other info that---truncated---
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix tags leak when shrink nr_hw_queuesAlthough we don't need to realloc set->tags[] when shrink nr_hw_queues,we need to free them. Or these tags will be leaked.How to reproduce:1. mount -t configfs configfs /mnt2. modprobe null_blk nr_devices=0 submit_queues=83. mkdir /mnt/nullb/nullb04. echo 1 > /mnt/nullb/nullb0/power5. echo 4 > /mnt/nullb/nullb0/submit_queues6. rmdir /mnt/nullb/nullb0In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), thenin step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).At last in step 6, only these 5 tags are freed, the other 4 tags leaked.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI/DOE: Fix destroy_work_on_stack() raceThe following debug object splat was observed in testing: ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510 WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0 ... Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? debug_print_object+0x7d/0xb0 ? __pfx_doe_statemachine_work+0x10/0x10 debug_object_free.part.0+0x11b/0x150 doe_statemachine_work+0x45e/0x510 process_one_work+0x1d4/0x3c0This occurs because destroy_work_on_stack() was called after signalingthe completion in the calling thread. This creates a race betweendestroy_work_on_stack() and the task->work struct going out of scope inpci_doe().Signal the work complete after destroying the work struct. This is safebecause signal_task_complete() is the final thing the work item does andthe workqueue code is careful not to access the work struct after.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Don't leak a resource on eviction errorOn eviction errors other than -EMULTIHOP we were leaking a resource.Fix.v2:- Avoid yet another goto (Andi Shyti)
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()'read' is freed when it is known to be NULL, but not when a read erroroccurs.Revert the logic to avoid a small leak, should a m920x_read() call fail.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: fix memory leak after finding block group with super blocksAt exclude_super_stripes(), if we happen to find a block group that hassuper blocks mapped to it and we are on a zoned filesystem, we error outas this is not supposed to happen, indicating either a bug or maybe somememory corruption for example. However we are exiting the function withoutfreeing the memory allocated for the logical address of the super blocks.Fix this by freeing the logical address.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Free IRQs before removing the deviceIn pci_endpoint_test_remove(), freeing the IRQs after removing the devicecreates a small race window for IRQs to be received with the test devicememory already released, causing the IRQ handler to access invalid memory,resulting in an oops.Free the device IRQs before removing the device to avoid this issue.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix locking order in ivpu_job_submitFix deadlock in job submission and abort handling.When a thread aborts currently executing jobs due to a fault,it first locks the global lock protecting submitted_jobs (#1).After the last job is destroyed, it proceeds to release the related contextand locks file_priv (#2). Meanwhile, in the job submission thread,the file_priv lock (#2) is taken first, and then the submitted_jobslock (#1) is obtained when a job is added to the submitted jobs list. CPU0 CPU1 ---- ---- (for example due to a fault) (jobs submissions keep coming) lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2This order of locking causes a deadlock. To resolve this issue,change the order of locking in ivpu_job_submit().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lockWhen netpoll is enabled, calling pr_warn_once() while holdingkmemleak_lock in mem_pool_alloc() can cause a deadlock due to lockinversion with the netconsole subsystem. This occurs becausepr_warn_once() may trigger netpoll, which eventually leads to__alloc_skb() and back into kmemleak code, attempting to reacquirekmemleak_lock.This is the path for the deadlock.mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);Fix this by setting a flag and issuing the pr_warn_once() afterkmemleak_lock is released.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix NULL pointer dereference in __dm_suspend()There is a race condition between dm device suspend and table load thatcan lead to null pointer dereference. The issue occurs when suspend isinvoked before table load completes:BUG: kernel NULL pointer dereference, address: 0000000000000054Oops: 0000 [#1] PREEMPT SMP PTICPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0The issue can be triggered as below:T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1)dm_stop_queue / dm_wait_for_completion=> q->tag_set NULL pointer! (2) => q->tag_set = set; (3)Fix this by checking if a valid table (map) exists before performingrequest-based suspend and waiting for target I/O. When map is NULL,skip these table-dependent suspend steps.Even when map is NULL, no I/O can reach any target because there isno table loaded; I/O submitted in this state will fail early in theDM layer. Skipping the table-dependent suspend logic in this caseis safe and avoids NULL pointer dereferences.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: verify orphan file size is not too bigIn principle orphan file can be arbitrarily large. However orphan replayneeds to traverse it all and we also pin all its buffers in memory. Thusfilesystems with absurdly large orphan files can lead to big amounts ofmemory consumed. Limit orphan file size to a sane value and also usekvmalloc() for allocating array of block descriptor structures to avoidlarge order allocations for sane but large orphan files.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: client: fix memory leak in smb3_fs_context_parse_paramThe user calls fsconfig twice, but when the program exits, free() onlyfrees ctx->source for the second fsconfig, not the first.Regarding fc->source, there is no code in the fs context related to itsmemory reclamation.To fix this memory leak, release the source memory corresponding to ctxor fc before each parsing.syzbot reported:BUG: memory leakunreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444BUG: memory leakunreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Fix timeout handlingWhen the CPU that the QSPI interrupt handler runs on (typically CPU 0)is excessively busy, it can lead to rare cases of the IRQ thread notrunning before the transfer timeout is reached.While handling the timeouts, any pending transfers are cleaned up andthe message that they correspond to is marked as failed, which leavesthe curr_xfer field pointing at stale memory.To avoid this, clear curr_xfer to NULL upon timeout and check for thiscondition when the IRQ thread is finally run.While at it, also make sure to clear interrupts on failure so that newinterrupts can be run.A better, more involved, fix would move the interrupt clearing into ahard IRQ handler. Ideally we would also want to signal that the IRQthread no longer needs to be run after the timeout is hit to avoid theextra check for a valid transfer.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lockblk_mq_{add,del}_queue_tag_set() functions add and remove queues fromtagset, the functions make sure that tagset and queues are marked asshared when two or more queues are attached to the same tagset.Initially a tagset starts as unshared and when the number of addedqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared alongwith all the queues attached to it. When the number of attached queuesdrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset andthe remaining queues as unshared.Both functions need to freeze current queues in tagset before setting onunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functionshold set->tag_list_lock mutex, which makes sense as we do not wantqueues to be added or deleted in the process. This used to work fineuntil commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset")made the nvme driver quiesce tagset instead of quiscing individualqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues inset->tag_list while holding set->tag_list_lock also.This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53The top stacktrace is showing nvme_timeout() called to handle nvmecommand timeout. timeout handler is trying to disable the controller andas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq notto call queue callback handlers. The thread is stuck waiting forset->tag_list_lock as it tries to walk the queues in set->tag_list.The lock is held by the second thread in the bottom stack which iswaiting for one of queues to be frozen. The queue usage counter willdrop to zero after nvme_timeout() finishes, and this will not happenbecause the thread will wait for this mutex forever.Given that [un]quiescing queue is an operation that does not need tosleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of takingset->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCUsafe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list)in blk_mq_del_queue_tag_set() because we can not re-initialize it whilethe list is being traversed under RCU. The deleted queue will not beadded/deleted to/from a tagset and it will be freed in blk_free_queue()after the end of RCU grace period.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't log conflicting inode if it's a dir moved in the current transactionWe can't log a conflicting inode if it's a directory and it was movedfrom one parent directory to another parent directory in the currenttransaction, as this can result an attempt to have a directory withtwo hard links during log replay, one for the old parent directory andanother for the new parent directory.The following scenario triggers that issue:1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory;2) We move "dir1" to some other directory;3) We create a file with the name "dir1" in directory inode A;4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1";5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name();6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory);7) We have a power failure;8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1".As a result after log replay finishes when we trigger writeback of thesubvolume tree's extent buffers, the tree check will detect that we havea directory a hard link count of 2 and we get a mount failure.The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [ 3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [ 3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [ 3845.737816] location key (257 1 0) type 2 [---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/amd: Check event before enable to avoid GPFOn AMD machines cpuc->events[idx] can become NULL in a subtle racecondition with NMI->throttle->x86_pmu_stop().Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.This appears to be an AMD only issue.Syzkaller reported a GPF in amd_pmu_enable_all.INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecsOops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzkRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430)RSP: 0018:ffff888118009d60 EFLAGS: 00010012RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0Call Trace: amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))x86_pmu_enable (arch/x86/events/core.c:1360)event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346)__perf_remove_from_context (kernel/events/core.c:2435)event_function (kernel/events/core.c:259)remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1))__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540)__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47))
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: xattr: fix null pointer deref in ext4_raw_inode()If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()lacks error checking, this will lead to a null pointer dereferencein ext4_raw_inode(), called right after ext4_get_inode_loc().Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: fix use-after-free on probe deferralThe driver is dropping the references taken to the larb devices duringprobe after successful lookup as well as on errors. This canpotentially lead to a use-after-free in case a larb device has not yetbeen bound to its driver so that the iommu driver probe defers.Fix this by keeping the references as expected while the iommu driver isbound.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix reference count leak when using error routes with nexthop objectsWhen a nexthop object is deleted, it is marked as dead and thenfib_table_flush() is called to flush all the routes that are using thedead nexthop.The current logic in fib_table_flush() is to only flush error routes(e.g., blackhole) when it is called as part of network namespacedismantle (i.e., with flush_all=true). Therefore, error routes are notflushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1As such, they keep holding a reference on the nexthop object which inturn holds a reference on the nexthop device, resulting in a referencecount leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2Fix by flushing error routes when their nexthop is marked as dead.IPv6 does not suffer from this problem.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: Fix a memory leak in tpm2_load_cmd'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode'but it is not freed in the failure paths. Address this by wrapping the blobinto with a cleanup helper.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: restore destructor on submit failurehandshake_req_submit() replaces sk->sk_destruct but never restores it whensubmission fails before the request is hashed. handshake_sk_destruct() thenreturns early and the original destructor never runs, leaking the socket.Restore sk_destruct on the error path.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock in wait_current_trans() due to ignored transaction typeWhen wait_current_trans() is called during start_transaction(), itcurrently waits for a blocked transaction without considering whetherthe given transaction type actually needs to wait for that particulartransaction state. The btrfs_blocked_trans_types[] array already defineswhich transaction types should wait for which transaction states, butthis check was missing in wait_current_trans().This can lead to a deadlock scenario involving two transactions andpending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction BThis can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!)Task bstore_kv_sync in btrfs_commit_transaction waiting for orderedextents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30Fix this by passing the transaction type to wait_current_trans() andchecking btrfs_blocked_trans_types[cur_trans->state] against the giventype before deciding to wait. This ensures that transaction types whichare allowed to join during certain blocked states will not unnecessarilywait and cause deadlocks.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: Fix RSS LUT NULL pointer crash on early ethtool operationsThe RSS LUT is not initialized until the interface comes up, causingthe following NULL pointer crash when ethtool operations like rxhash on/offare performed before the interface is brought up for the first time.Move RSS LUT initialization from ndo_open to vport creation to ensure LUTis always available. This enables RSS configuration via ethtool beforebringing the interface up. Simplify LUT management by maintaining allchanges in the driver's soft copy and programming zeros to the indirectiontable when rxhash is disabled. Defer HW programming until the interfacecomes up if it is down during rxhash and LUT configuration changes.Steps to reproduce:** Load idpf driver; interfaces will be created modprobe idpf** Before bringing the interfaces up, turn rxhash off ethtool -K eth2 rxhash off[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000[89408.371908] #PF: supervisor read access in kernel mode[89408.371924] #PF: error_code(0x0000) - not-present page[89408.371940] PGD 0 P4D 0[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130[89408.372310] Call Trace:[89408.372317] [89408.372326] ? idpf_set_features+0xfc/0x180 [idpf][89408.372363] __netdev_update_features+0x295/0xde0[89408.372384] ethnl_set_features+0x15e/0x460[89408.372406] genl_family_rcv_msg_doit+0x11f/0x180[89408.372429] genl_rcv_msg+0x1ad/0x2b0[89408.372446] ? __pfx_ethnl_set_features+0x10/0x10[89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10[89408.372482] netlink_rcv_skb+0x58/0x100[89408.372502] genl_rcv+0x2c/0x50[89408.372516] netlink_unicast+0x289/0x3e0[89408.372533] netlink_sendmsg+0x215/0x440[89408.372551] __sys_sendto+0x234/0x240[89408.372571] __x64_sys_sendto+0x28/0x30[89408.372585] x64_sys_call+0x1909/0x1da0[89408.372604] do_syscall_64+0x7a/0xfa0[89408.373140] ? clear_bhb_loop+0x60/0xb0[89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e[89408.378887]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()The for_each_available_child_of_node() calls of_node_put() torelease child_np in each success loop. After breaking from theloop with the child_np has been released, the code will jump tothe put_child label and will call the of_node_put() again if thedevm_request_threaded_irq() fails. These cause a double free bug.Fix by returning directly to avoid the duplicate of_node_put().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix a deadlock when returning a delegation during open()Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935The issue is that the delegreturn is being asked to wait for a layoutreturn that cannot complete because a state recovery was initiated. Thestate recovery cannot complete until the open() finishes processing thedelegations it was given.The solution is to propagate the existing flags that indicate anon-blocking call to the function pnfs_roc(), so that it knows not towait in this situation.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a deadlock involving nfs_release_folio()Wang Zhaolong reports a deadlock involving NFSv4.1 state recoverywaiting on kthreadd, which is attempting to reclaim memory by callingnfs_release_folio(). The latter cannot make progress due to staterecovery being needed.It seems that the only safe thing to do here is to kick off a writebackof the folio, without waiting for completion, or else kicking off anasynchronous commit.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix potential underflow in virtio_transport_get_credit()The credit calculation in virtio_transport_get_credit() uses unsignedarithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);If the peer shrinks its advertised buffer (peer_buf_alloc) while bytesare in flight, the subtraction can underflow and produce a largepositive value, potentially allowing more data to be queued than thepeer can handle.Reuse virtio_transport_has_space() which already handles this case andadd a comment to make it clear why we are doing that.[Stefano: use virtio_transport_has_space() instead of duplicating the code][Stefano: tweak the commit message]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_agThis is more of a preventive patch to make the code more consistent andto prevent possible exploits that employ child qlen manipulations on qfq.use cl_is_active instead of relying on the child qdisc's qlen to determineclass activation.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Wake up the error handler when final completions race against each otherThe fragile ordering between marking commands completed or failed sothat the error handler only wakes when the last running commandcompletes or times out has race conditions. These race conditions cancause the SCSI layer to fail to wake the error handler, leaving I/Othrough the SCSI host stuck as the error state cannot advance.First, there is an memory ordering issue within scsi_dec_host_busy().The write which clears SCMD_STATE_INFLIGHT may be reordered with readscounting in scsi_host_busy(). While the local CPU will see its ownwrite, reordering can allow other CPUs in scsi_dec_host_busy() orscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU tosee a host busy equal to the host_failed count.This race condition can be prevented with a memory barrier on the errorpath to force the write to be visible before counting host busycommands.Second, there is a general ordering issue with scsi_eh_inc_host_failed(). Bycounting busy commands before incrementing host_failed, it can race with afinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() doesnot see host_failed incremented but scsi_eh_inc_host_failed() counts busycommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),resulting in neither waking the error handler task.This needs the call to scsi_host_busy() to be moved after host_failed isincremented to close the race condition.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Don't clobber irqfd routing type when deassigning irqfdWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ'srouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, tohandle a concurrent routing update, verify that the irqfd is still activebefore consuming the routing information. As evidenced by the x86 andarm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),clobbering the entry type without notifying arch code is surprising anderror prone.As a bonus, checking that the irqfd is active provides a convenientlocation for documenting _why_ KVM must not consume the routing entry foran irqfd that is in the process of being deassigned: once the irqfd isdeleted from the list (which happens *before* the eventfd is detached), itwill no longer receive updates via kvm_irq_routing_update(), and so KVMcould deliver an event using stale routing information (relative toKVM_SET_GSI_ROUTING returning to userspace).As an even better bonus, explicitly checking for the irqfd being activefixes a similar bug to the one the clobbering is trying to prevent: if anirqfd is deactivated, and then its routing is changed,kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()(because the irqfd isn't in the list). And so if the irqfd is in bypassmode, IRQs will continue to be posted using the old routing information.As for kvm_arch_irq_bypass_del_producer(), clobbering the routing typeresults in KVM incorrectly keeping the IRQ in bypass mode, which isespecially problematic on AMD as KVM tracks IRQs that are being posted toa vCPU in a list whose lifetime is tied to the irqfd.Without the help of KASAN to detect use-after-free, the most commonsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due tothe memory for irqfd structure being re-allocated and zeroed, resultingin irqfd->irq_bypass_data being NULL when read byavic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]---If AVIC is inhibited when the irfd is deassigned, the bug will manifest aslist corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: NFSv4 file creation neglects setting ACLAn NFSv4 client that sets an ACL with a named principal during filecreation retrieves the ACL afterwards, and finds that it is only adefault ACL (based on the mode bits) and not the ACL that wasrequested during file creation. This violates RFC 8881 section6.4.1.3: "the ACL attribute is set as given".The issue occurs in nfsd_create_setattr(), which callsnfsd_attrs_valid() to determine whether to call nfsd_setattr().However, nfsd_attrs_valid() checks only for iattr changes andsecurity labels, but not POSIX ACLs. When only an ACL is present,the function returns false, nfsd_setattr() is skipped, and thePOSIX ACL is never applied to the inode.Subsequently, when the client retrieves the ACL, the server findsno POSIX ACL on the inode and returns one generated from the file'smode bits rather than returning the originally-specified ACL.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A flaw was found in github.com/go-viper/mapstructure/v2, in the field processing component using mapstructure.WeakDecode. This vulnerability allows information disclosure through detailed error messages that may leak sensitive input values via malformed user-supplied data processed in security-critical contexts.
Packages affected:
docker > 0-0 (version in image is 28.5.1_ce-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: Discard stale CPU state when handling SME trapsThe logic for handling SME traps manipulates saved FPSIMD/SVE/SME stateincorrectly, and a race with preemption can result in a task havingTIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SME traps enabled). This can result in warnings fromdo_sme_acc() where SME traps are not expected while TIF_SME is set:| /* With TIF_SME userspace shouldn't generate any traps */| if (test_and_set_thread_flag(TIF_SME))| WARN_ON(1);This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")The race can occur when the SME trap handler is preempted before andafter manipulating the saved FPSIMD/SVE/SME state, starting and ending onthe same CPU, e.g.| void do_sme_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SME clear, SME traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| /* With TIF_SME userspace shouldn't generate any traps */| if (test_and_set_thread_flag(TIF_SME))| WARN_ON(1);|| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| unsigned long vq_minus_one =| sve_vq_from_vl(task_get_sme_vl(current)) - 1;| sme_set_vq(vq_minus_one);|| fpsimd_bind_task_to_cpu();| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SME traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.Note: this was originallly posted as [1].[ Rutland: rewrite commit message ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/vmem: split pages when debug pagealloc is enabledSince commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")the kernel crashes early during boot when debug pagealloc is enabled:mem auto-init: stack:off, heap alloc:off, heap free:offaddressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOCModules linked in:CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630[..]Krnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e 00000000001325fc: eb880002000c srlg %r8,%r8,2 #0000000000132602: b2210051 ipte %r5,%r1,%r0,0 >0000000000132606: b90400d1 lgr %r13,%r1 000000000013260a: 41605008 la %r6,8(%r5) 000000000013260e: a7db1000 aghi %r13,4096 0000000000132612: b221006d ipte %r6,%r13,%r0,0 0000000000132616: e3d0d0000171 lay %r13,4096(%r13)Call Trace: __kernel_map_pages+0x14e/0x320 __free_pages_ok+0x23a/0x5a8) free_low_memory_core_early+0x214/0x2c8 memblock_free_all+0x28/0x58 mem_init+0xb6/0x228 mm_core_init+0xb6/0x3b0 start_kernel+0x1d2/0x5a8 startup_continue+0x36/0x40Kernel panic - not syncing: Fatal exception: panic_on_oopsThis is caused by using large mappings on machines with EDAT1/EDAT2. Addthe code to split the mappings into 4k pages if debug pagealloc is enabledby CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernelcommand line option.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
containerd > 0-0 (version in image is 1.7.29-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Log an error when close_all_cached_dirs failsUnder low-memory conditions, close_all_cached_dirs() can't move thedentries to a separate list to dput() them once the locks are dropped.This will result in a "Dentry still in use" error, so add an errormessage that makes it clear this is what happened:[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries[ 495.281595] ------------[ cut here ]------------[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs][ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0Also, bail out of looping through all tcons as soon as a singleallocation fails, since we're already in trouble, and kmalloc() attemptsfor subseqeuent tcons are likely to fail just like the first one did.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - request reserved interrupt for virtual functionThe device interrupt vector 3 is an error interrupt forphysical function and a reserved interrupt for virtual function.However, the driver has not registered the reserved interrupt forvirtual function. When allocating interrupts, the number of interruptsis allocated based on powers of two, which includes this interrupt.When the system enables GICv4 and the virtual function passthroughto the virtual machine, releasing the interrupt in the drivertriggers a warning.The WARNING report is:WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4Therefore, register a reserved interrupt for VF and set theIRQF_NO_AUTOEN flag to avoid that warning.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()The ethtool tsconfig Netlink path can trigger a null pointerdereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower()results in generic_hwtstamp_ioctl_lower() being called withkernel_cfg->ifr as NULL.The generic_hwtstamp_ioctl_lower() function does not expecta NULL ifr and dereferences it, leading to a system crash.Fix this by adding a NULL check for kernel_cfg->ifr ingeneric_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Don't overflow during division for dirty trackingIf pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflowto 0 and this triggers divide by 0.In this case the index should just be 0, so reorganize things to divideby shift and avoid hitting any overflows.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: validate skb length for unknown CC opcodeIn hci_cmd_complete_evt(), if the command complete event has an unknownopcode, we assume the first byte of the remaining skb->data contains thereturn status. However, parameter data has previously been pulled inhci_event_func(), which may leave the skb empty. If so, using skb->data[0]for the return status uses un-init memory.The fix is to check skb->len before using skb->data.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix nullptr err of vm_handle_movedIf a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL.So, such kind of amdgpu_bo_va should be updated separately beforeamdgpu_vm_handle_moved.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Free special fields when update [lru_,]percpu_hash mapsAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missingcalls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause thememory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until themap gets freed.Fix this by calling 'bpf_obj_free_fields()' after'copy_map_value[,_long]()' in 'pcpu_copy_value()'.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flagsWhen a filesystem is being automounted, it needs to preserve theuser-set superblock mount options, such as the "ro" flag.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: fix invalid array index in rose_kill_by_device()rose_kill_by_device() collects sockets into a local array[] and theniterates over them to disconnect sockets bound to a device being broughtdown.The loop mistakenly indexes array[cnt] instead of array[i]. For cnt
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: Fix RSS LUT NULL ptr issue after soft resetDuring soft reset, the RSS LUT is freed and not restored unless theinterface is up. If an ethtool command that accesses the rss lut isattempted immediately after reset, it will result in NULL ptrdereference. Also, there is no need to reset the rss lut if the soft resetdoes not involve queue count change.After soft reset, set the RSS LUT to default values based on the updatedqueue count only if the reset was a result of a queue count change andthe LUT was not configured by the user. In all other cases, don't touchthe LUT.Steps to reproduce:** Bring the interface down (if up)ifconfig eth1 down** update the queue count (eg., 27->20)ethtool -L eth1 combined 20** display the RSS LUTethtool -x eth1[82375.558338] BUG: kernel NULL pointer dereference, address: 0000000000000000[82375.558373] #PF: supervisor read access in kernel mode[82375.558391] #PF: error_code(0x0000) - not-present page[82375.558408] PGD 0 P4D 0[82375.558421] Oops: Oops: 0000 [#1] SMP NOPTI[82375.558516] RIP: 0010:idpf_get_rxfh+0x108/0x150 [idpf][82375.558786] Call Trace:[82375.558793] [82375.558804] rss_prepare.isra.0+0x187/0x2a0[82375.558827] rss_prepare_data+0x3a/0x50[82375.558845] ethnl_default_doit+0x13d/0x3e0[82375.558863] genl_family_rcv_msg_doit+0x11f/0x180[82375.558886] genl_rcv_msg+0x1ad/0x2b0[82375.558902] ? __pfx_ethnl_default_doit+0x10/0x10[82375.558920] ? __pfx_genl_rcv_msg+0x10/0x10[82375.558937] netlink_rcv_skb+0x58/0x100[82375.558957] genl_rcv+0x2c/0x50[82375.558971] netlink_unicast+0x289/0x3e0[82375.558988] netlink_sendmsg+0x215/0x440[82375.559005] __sys_sendto+0x234/0x240[82375.559555] __x64_sys_sendto+0x28/0x30[82375.560068] x64_sys_call+0x1909/0x1da0[82375.560576] do_syscall_64+0x7a/0xfa0[82375.561076] ? clear_bhb_loop+0x60/0xb0[82375.561567] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leakIn gs_can_open(), the URBs for USB-in transfers are allocated, added to theparent->rx_submitted anchor and submitted. In the complete callbackgs_usb_receive_bulk_callback(), the URB is processed and resubmitted. Ings_can_close() the URBs are freed by callingusb_kill_anchored_urbs(parent->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in gs_can_close().Fix the memory leak by anchoring the URB in thegs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_listWhen the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() isset to false, the driver may request the PMAC_ID from the firmware of thenetwork card, and this function will store that PMAC_ID at the providedaddress pmac_id. This is the contract of this function.However, there is a location within the driver where bothpmac_id_valid == false and pmac_id == NULL are being passed. This couldresult in dereferencing a NULL pointer.To resolve this issue, it is necessary to pass the address of a stubvariable to the function.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers areallocated, added to the priv->rx_submitted anchor and submitted. In thecomplete callback usb_8dev_read_bulk_callback(), the URBs are processed andresubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed bycalling usb_kill_anchored_urbs(&priv->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in theusb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix memory leak in rx_desc and tx_descCurrently when ath12k_dp_cc_desc_init() is called we allocatememory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), duringdescriptor cleanup rx_descs and tx_descs memory is not freed.This is cause of memory leak. These allocated memory should befreed in ath12k_dp_cc_cleanup.In ath12k_dp_cc_desc_init(), we can save base address of rx_descsand tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs andtx_descs memory using their base address.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: When libcurl is asked to perform automatic gzip decompression ofcontent-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow wouldmake libcurl perform a buffer overflow.
Packages affected:
curl > 0-0 (version in image is 8.14.1-slfo.1.1_5.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: add bounds check for if_id in IRQ handlerThe IRQ handler extracts if_id from the upper 16 bits of the hardwarestatus register and uses it to index into ethsw->ports[] withoutvalidation. Since if_id can be any 16-bit value (0-65535) but the portsarray is only allocated with sw_attr.num_ifs elements, this can lead toan out-of-bounds read potentially.Add a bounds check before accessing the array, consistent with theexisting validation in dpaa2_switch_rx().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zeroThe driver allocates arrays for ports, FDBs, and filter blocks usingkcalloc() with ethsw->sw_attr.num_ifs as the element count. When thedevice reports zero interfaces (either due to hardware configurationor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)instead of NULL.Later in dpaa2_switch_probe(), the NAPI initialization unconditionallyaccesses ethsw->ports[0]->netdev, which attempts to dereferenceZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.Add a check to ensure num_ifs is greater than zero after retrievingdevice attributes. This prevents the zero-sized allocations andsubsequent invalid pointer dereference.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hidraw: fix data race on device refcountThe hidraw_open() function increments the hidraw device referencecounter. The counter has no dedicated synchronization mechanism,resulting in a potential data race when concurrently opening a device.The race is a regression introduced by commit 8590222e4b02 ("HID:hidraw: Replace hidraw device table mutex with a rwsem"). Whileminors_rwsem is intended to protect the hidraw_table itself, by insteadacquiring the lock for writing, the reference counter is also protected.This is symmetrical to hidraw_release().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: skip splitting and logical rewriting on pre-alloc writeWhen doing a relocation, there is a chance that at the time ofbtrfs_reloc_clone_csums(), there is no checksum for the correspondingregion.In this case, btrfs_finish_ordered_zoned()'s sum points to an invalid itemand so ordered_extent's logical is set to some invalid value. Then,btrfs_lookup_block_group() in btrfs_zone_finish_endio() failed to find ablock group and will hit an assert or a null pointer dereference asfollowing.This can be reprodcued by running btrfs/028 several times (e.g, 4 to 16times) with a null_blk setup. The device's zone size and capacity is set to32 MB and the storage size is set to 5 GB on my setup. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 6 PID: 3105720 Comm: kworker/u16:13 Tainted: G W 6.5.0-rc6-kts+ #1 Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] Code: 41 54 49 89 fc 55 48 89 f5 53 e8 57 7d fc ff 48 8d b8 88 00 00 00 48 89 c3 48 b8 00 00 00 00 00 > 3c 02 00 0f 85 02 01 00 00 f6 83 88 00 00 00 01 0f 84 a8 00 00 RSP: 0018:ffff88833cf87b08 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed102877b827 R10: ffff888143bdc13b R11: ffff888125b1cbc0 R12: ffff888143bdc000 R13: 0000000000007000 R14: ffff888125b1cba8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88881e500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3ed85223d5 CR3: 00000001519b4005 CR4: 00000000001706e0 Call Trace: ? die_addr+0x3c/0xa0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] ? btrfs_zone_finish_endio.part.0+0x19/0x160 [btrfs] btrfs_finish_one_ordered+0x7b8/0x1de0 [btrfs] ? rcu_is_watching+0x11/0xb0 ? lock_release+0x47a/0x620 ? btrfs_finish_ordered_zoned+0x59b/0x800 [btrfs] ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs] ? btrfs_finish_ordered_zoned+0x358/0x800 [btrfs] ? __smp_call_single_queue+0x124/0x350 ? rcu_is_watching+0x11/0xb0 btrfs_work_helper+0x19f/0xc60 [btrfs] ? __pfx_try_to_wake_up+0x10/0x10 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 process_one_work+0x8c1/0x1430 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? _raw_spin_lock_irq+0x52/0x60 worker_thread+0x100/0x12c0 ? __kthread_parkme+0xc1/0x1f0 ? __pfx_worker_thread+0x10/0x10 kthread+0x2ea/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 On the zoned mode, writing to pre-allocated region means data relocationwrite. Such write always uses WRITE command so there is no need of splittingand rewriting logical address. Thus, we can just skip the function for thecase.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipa: only reset hashed tables when supportedLast year, the code that manages GSI channel transactions switchedfrom using spinlock-protected linked lists to using indexes into thering buffer used for a channel. Recently, Google reported seeingtransaction reference count underflows occasionally during shutdown.Doug Anderson found a way to reproduce the issue reliably, andbisected the issue to the commit that eliminated the linked listsand the lock. The root cause was ultimately determined to berelated to unused transactions being committed as part of the modemshutdown cleanup activity. Unused transactions are not normallyexpected (except in error cases).The modem uses some ranges of IPA-resident memory, and whenever itshuts down we zero those ranges. In ipa_filter_reset_table() atransaction is allocated to zero modem filter table entries. Ifhashing is not supported, hashed table memory should not be zeroed.But currently nothing prevents that, and the result is an unusedtransaction. Something similar occurs when we zero routing tableentries for the modem.By preventing any attempt to clear hashed tables when hashing is notsupported, the reference count underflow is avoided in this case.Note that there likely remains an issue with properly freeing unusedtransactions (if they occur due to errors). This patch addressesonly the underflows that Google originally reported.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before initblk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0This happens because iocg->ioc is NULL. The field is initialized byioc_pd_init() and never cleared. The NULL deref is caused byblkcg_activate_policy() installing blkg_policy_data before initializing it.blkcg_activate_policy() was doing the following:1. Allocate pd's for all existing blkg's and install them in blkg->pd[].2. Initialize all pd's.3. Online all pd's.blkcg_activate_policy() only grabs the queue_lock and may release andre-acquire the lock as allocation may need to sleep. ioc_weight_write()grabs blkcg->lock and iterates all its blkg's. The two can race and ifioc_weight_write() runs during #1 or between #1 and #2, it can encounter apd which is not initialized yet, leading to crash.The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c "echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weightwith the following patch applied:> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c> index fc49be622e05..38d671d5e10c 100644> --- a/block/blk-cgroup.c> +++ b/block/blk-cgroup.c> @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)> pd->online = false;> }>> + if (system_state == SYSTEM_RUNNING) {> + spin_unlock_irq(&q->queue_lock);> + ssleep(1);> + spin_lock_irq(&q->queue_lock);> + }> +> /* all allocated, init in the same order */> if (pol->pd_init_fn)> list_for_each_entry_reverse(blkg, &q->blkg_list, q_node)I don't see a reason why all pd's should be allocated, initialized andonlined together. The only ordering requirement is that parent blkgs to beinitialized and onlined before children, which is guaranteed from thewalking order. Let's fix the bug by allocating, initializing and onlining pdfor each blkg and holding blkcg->lock over initialization and onlining. Thisensures that an installed blkg is always fully initialized and onlinedremoving the the race window.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0and sctp_ulpevent_make_authkey() returns 0, then the variableai_ev remains zero and the zero will be dereferencedin the sctp_ulpevent_free() function.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix invalid prog->stats access when update_effective_progs failsSyzkaller triggers an invalid memory access issue following faultinjection in update_effective_progs. The issue can be described asfollows:__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog---softirq start---__do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp)---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype])The reason is that fault injection caused update_effective_progs to failand then changed the original prog into dummy_bpf_prog.prog inpurge_effective_progs. Then a softirq came, and accessing the members ofdummy_bpf_prog.prog in the softirq triggers invalid mem access.To fix it, skip updating stats when stats is NULL.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actualuser on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.
Packages affected:
podman > 0-0 (version in image is 5.4.2-slfo.1.1_3.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Add a upper bound on max_vclockssyzbot reported WARNING in max_vclocks_store.This occurs when the argument max is too large for kcalloc to handle.Extend the guard to guard against values that are too large forkcalloc
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
libldap2 > 0-0 (version in image is 2.6.4-slfo.1.1_1.2).
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
Packages affected:
libncurses6 > 0-0 (version in image is 6.4.20240224-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: fix possible memory leak in ibmebus_bus_init()If device_register() returns error in ibmebus_bus_init(), name of kobjectwhich is allocated in dev_set_name() called in device_add() is leaked.As comment of device_add() says, it should call put_device() to dropthe reference count that was set in device_initialize() when it fails,so the name can be freed in kobject_cleanup().
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: don't overflow multishot recvDon't allow overflowing multishot recv CQEs, it might get out ofhand, hurt performance, and in the worst case scenario OOM the task.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/client: Fix memory leak in drm_client_target_cloneddmt_mode is allocated and never freed in this function.It was found with the ast driver, but most drivers using generic fbdevsetup are probably affected.This fixes the following kmemleak report: backtrace: [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm] [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm] [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm] [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm] [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast] [<00000000987f19bb>] local_pci_probe+0xdc/0x180 [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0 [<0000000000b85301>] process_one_work+0x8b7/0x1540 [<000000003375b17c>] worker_thread+0x70a/0xed0 [<00000000b0d43cd9>] kthread+0x29f/0x340 [<000000008d770833>] ret_from_fork+0x1f/0x30unreferenced object 0xff11000333089a00 (size 128):
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuseA syzbot stress test using a corrupted disk image reported thatmark_buffer_dirty() called from __nilfs_mark_inode_dirty() ornilfs_palloc_commit_alloc_entry() may output a kernel warning, and canpanic if the kernel is booted with panic_on_warn.This is because nilfs2 keeps buffer pointers in local structures for somemetadata and reuses them, but such buffers may be forcibly discarded bynilfs_clear_dirty_page() in some critical situations.This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: donot write dirty data after degenerating to read-only"), but the issue haspotentially existed before.Fix this issue by checking the uptodate flag when attempting to reuse aninternally held buffer, and reloading the metadata instead of reusing thebuffer if the flag was lost.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfreeThe call stack shown below is a scenario in the Linux 4.19 kernel.Allocating memory failed where exfat fs use kmalloc_array due tosystem memory fragmentation, while the u-disk was inserted withoutrecognition.Devices such as u-disk using the exfat file system are pluggable andmay be insert into the system at any time.However, long-term running systems cannot guarantee the continuity ofphysical memory. Therefore, it's necessary to address this issue.Binder:2632_6: page allocation failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)Call trace:[242178.097582] dump_backtrace+0x0/0x4[242178.097589] dump_stack+0xf4/0x134[242178.097598] warn_alloc+0xd8/0x144[242178.097603] __alloc_pages_nodemask+0x1364/0x1384[242178.097608] kmalloc_order+0x2c/0x510[242178.097612] kmalloc_order_trace+0x40/0x16c[242178.097618] __kmalloc+0x360/0x408[242178.097624] load_alloc_bitmap+0x160/0x284[242178.097628] exfat_fill_super+0xa3c/0xe7c[242178.097635] mount_bdev+0x2e8/0x3a0[242178.097638] exfat_fs_mount+0x40/0x50[242178.097643] mount_fs+0x138/0x2e8[242178.097649] vfs_kern_mount+0x90/0x270[242178.097655] do_mount+0x798/0x173c[242178.097659] ksys_mount+0x114/0x1ac[242178.097665] __arm64_sys_mount+0x24/0x34[242178.097671] el0_svc_common+0xb8/0x1b8[242178.097676] el0_svc_handler+0x74/0x90[242178.097681] el0_svc+0x8/0x340By analyzing the exfat code,we found that continuous physical memoryis not required here,so kvmalloc_array is used can solve this problem.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx93: fix memory leak and missing unwind goto in imx93_clocks_probeIn function probe(), it returns directly without unregistered hwswhen error occurs.Fix this by adding 'goto unregister_hws;' on line 295 andline 310.Use devm_kzalloc() instead of kzalloc() to automaticallyfree the memory using devm_kfree() when error occurs.Replace of_iomap() with devm_of_iomap() to automaticallyhandle the unused ioremap region and delete 'iounmap(anatop_base);'in unregister_hws.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.
Packages affected:
iproute2 > 0-0 (version in image is 6.3-slfo.1.1_1.2).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
python311 > 0-0 (version in image is 3.11.14-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error pathsWhen processing mount options, efivarfs allocates efivarfs_fs_info (sfi)early in fs_context initialization. However, sfi is associated with thesuperblock and typically freed when the superblock is destroyed. If thefs_context is released (final put) before fill_super is called-such ason error paths or during reconfiguration-the sfi structure would leak,as ownership never transfers to the superblock.Implement the .free callback in efivarfs_context_ops to ensure anyallocated sfi is properly freed if the fs_context is torn down beforefill_super, preventing this memory leak.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: support mapping cb with vmalloc-backed coherent memoryWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may returnaddresses from the vmalloc range. If such an address is mapped withoutVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to theVM_PFNMAP restriction.Fix this by checking for vmalloc addresses and setting VM_MIXEDMAPin the VMA before mapping. This ensures safe mapping and avoids kernelcrashes. The memory is still driver-allocated and cannot be accesseddirectly by userspace.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: validate PHY address before useThe ASIX driver reads the PHY address from the USB device viaasix_read_phy_addr(). A malicious or faulty device can return aninvalid address (>= PHY_MAX_ADDR), which causes a warning inmdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76Validate the PHY address in asix_read_phy_addr() and remove thenow-redundant check in ax88172a.c.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid chain re-validation if possibleHamza Mahfooz reports cpu soft lock-ups innft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547][..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables][..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables][..]Currently nf_tables will traverse the entire table (chain graph), startingfrom the entry points (base chains), exploring all possible paths(chain jumps). But there are cases where we could avoid revalidation.Consider:1 input -> j2 -> j32 input -> j2 -> j33 input -> j1 -> j2 -> j3Then the second rule does not need to revalidate j2, and, by extension j3,because this was already checked during validation of the first rule.We need to validate it only for rule 3.This is needed because chain loop detection also ensures we do not exceedthe jump stack: Just because we know that j2 is cycle free, its last jumpmight now exceed the allowed stack size. We also need to update allreachable chains with the new largest observed call depth.Care has to be taken to revalidate even if the chain depth won't be anissue: chain validation also ensures that expressions are not called frominvalid base chains. For example, the masquerade expression can only becalled from NAT postrouting base chains.Therefore we also need to keep record of the base chain context (type,hooknum) and revalidate if the chain becomes reachable from a differenthook location.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
gettext-runtime > 0-0 (version in image is 0.21.1-slfo.1.1_2.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.
Packages affected:
libxml2-2 > 0-0 (version in image is 2.11.6-slfo.1.1_7.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix kmemleak by releasing references to fault configfs itemsWhen CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blkdriver sets up fault injection support by creating the timeout_inject,requeue_inject, and init_hctx_fault_inject configfs items as childrenof the top-level nullbX configfs group.However, when the nullbX device is removed, the references taken tothese fault-config configfs items are not released. As a result,kmemleak reports a memory leak, for example:unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ecFix this by explicitly releasing the references to the fault-configconfigfs items when dropping the reference to the top-level nullbXconfigfs group.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,the function jumps to the out_scratch label without freeing the alreadyallocated dsaddrs list, leading to a memory leak.Fix this by jumping to the out_err_drain_dsaddrs label, which properlyfrees the dsaddrs list before cleaning up other resources.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Don't allow 0 for FOU_ATTR_IPPROTO.fou_udp_recv() has the same problem mentioned in the previouspatch.If FOU_ATTR_IPPROTO is set to 0, skb is not freed byfou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().Let's forbid 0 for FOU_ATTR_IPPROTO.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-slfo.1.1_1.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: glink: fix off-by-one in connector_statusUCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS.Correct the condition in the pmic_glink_ucsi_connector_status()callback, fixing Type-C orientation reporting for the third USB-Cconnector.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cm: Fix leaking the multicast GID table referenceIf the CM ID is destroyed while the CM event for multicast creating isstill queued the cancel_work_sync() will prevent the work from runningwhich also prevents destroying the ah_attr. This leaks a refcount andtriggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886Destroy the ah_attr after canceling the work, it is safe to call thistwice.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
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:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Silence a warning in btf_type_id_size()syzbot reported a warning in [1] with the following stacktrace: WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... Call Trace: map_check_btf kernel/bpf/syscall.c:1024 [inline] map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198 __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040 __do_sys_bpf kernel/bpf/syscall.c:5162 [inline] __se_sys_bpf kernel/bpf/syscall.c:5160 [inline] __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160 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/0xcdWith the following btf [1] DECL_TAG 'a' type_id=4 component_idx=-1 [2] PTR '(anon)' type_id=0 [3] TYPE_TAG 'a' type_id=2 [4] VAR 'a' type_id=3, linkage=staticand when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),the following WARN_ON_ONCE in btf_type_id_size() is triggered: if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) && !btf_type_is_var(size_type))) return NULL;Note that 'return NULL' is the correct behavior as we don't wanta DECL_TAG type to be used as a btf_{key,value}_type_id evenfor the case like 'DECL_TAG -> STRUCT'. So thereis no correctness issue here, we just want to silence warning.To silence the warning, I added DECL_TAG as one of kinds inbtf_type_nosize() which will cause btf_type_id_size() returningNULL earlier without the warning. [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPTlppaca_shared_proc() takes a pointer to the lppaca which is typicallyaccessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leadsto checking if preemption is enabled, for example: BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693 caller is lparcfg_data+0x408/0x19a0 CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2 Call Trace: dump_stack_lvl+0x154/0x200 (unreliable) check_preemption_disabled+0x214/0x220 lparcfg_data+0x408/0x19a0 ...This isn't actually a problem however, as it does not matter whichlppaca is accessed, the shared proc state will be the same.vcpudispatch_stats_procfs_init() already works around this by disablingpreemption, but the lparcfg code does not, erroring any time/proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.Instead of disabling preemption on the caller side, reworklppaca_shared_proc() to not take a pointer and instead directly accessthe lppaca, bypassing any potential preemption checks.[mpe: Rework to avoid needing a definition in paca.h and lppaca.h]
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Fix crash in icl_update_topdown_event()The perf_fuzzer found a hard-lockup crash on a RaptorLake machine: Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210CPUs 16-23 are E-core CPUs that don't support the perf metrics feature.The icl_update_topdown_event() should not be invoked on these CPUs.It's a regression of commit: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")The bug introduced by that commit is that the is_topdown_event() functionis mistakenly used to replace the is_topdown_count() call to check if thetopdown functions for the perf metrics feature should be invoked.Fix it.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Prevent access to vCPU events before initAnother day, another syzkaller bug. KVM erroneously allows userspace topend vCPU events for a vCPU that hasn't been initialized yet, leading toKVM interpreting a bunch of uninitialized garbage for routing /injecting the exception.In one case the injection code and the hyp disagree on whether the vCPUhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)Reject the ioctls outright as no sane VMM would call these beforeKVM_ARM_VCPU_INIT anyway. Even if it did the exception would've beenthrown away by the eventual reset of the vCPU's state.
Packages affected:
kernel-default < 6.4.0-39.1 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-38.1).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).
Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-slfo.1.1_1.5).
SL-Micro-release == 6.1 (version in image is 6.1-slfo.1.12.10).