-
Description: When a non-x86 platform is detected, cloud-init grants root access to a hardcoded url with a local IP address. To prevent this, cloud-init default configurations disable platform enumeration.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.12.1).
-
Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- tar > 0-0 (version in image is 1.34-150000.3.34.1).
-
Description: An undocumented and unsafe feature in the PLY (Python Lex-Yacc) library 3.11 allows Remote Code Execution (RCE) via the `picklefile` parameter in the `yacc()` function. This parameter accepts a `.pkl` file that is deserialized with `pickle.load()` without validation. Because `pickle` allows execution of embedded code via `__reduce__()`, an attacker can achieve code execution by passing a malicious pickle file. The parameter is not mentioned in official documentation or the GitHub repository, yet it is active in the PyPI version. This introduces a stealthy backdoor and persistence risk.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-ply > 0-0 (version in image is 3.11-150400.12.6.1).
-
Description: Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc.Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc > 0-0 (version in image is 2.38-150600.14.37.1).
-
Description: The mkdumprd script called "dracut" in the current working directory "." allows local users to trick the administrator into executing code as root.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- kdump < 2.0.18-150700.1.2 (version in image is 2.0.18+git2.g881ca8c-150700.3.3.2).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).
-
Description: SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix ipv4 null-ptr-deref in route error pathThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()without ensuring skb->dev is set, leading to a NULL pointer dereferencein fib_compute_spec_dst() when ipv4_link_failure() attempts to sendICMP destination unreachable messages.The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip optionsin ipv4_link_failure") started calling __ip_options_compile() fromipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()which dereferences skb->dev. An attempt was made to fix the NULL skb->devdereference in commit 0113d9c9d1cc ("ipv4: fix null-deref inipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)dereference by using a fallback device. The fix was incomplete becausefib_compute_spec_dst() later in the call chain still accesses skb->devdirectly, which remains NULL when IPVS calls dst_link_failure().The crash occurs when:1. IPVS processes a packet in NAT mode with a misconfigured destination2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route3. The error path calls dst_link_failure(skb) with skb->dev == NULL4. ipv4_link_failure() -> ipv4_send_dest_unreach() -> __ip_options_compile() -> fib_compute_spec_dst()5. fib_compute_spec_dst() dereferences NULL skb->devApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fixipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev beforecalling dst_link_failure().KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285Call Trace: spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a zip bomb to be used to execute a DoS against the AIOHTTP server. An attacker may be able to send a compressed request that when decompressed by AIOHTTP could exhaust the host's memory. This issue is fixed in version 3.13.3.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow for an infinite loop to occur when assert statements are bypassed, resulting in a DoS attack when processing a POST body. If optimizations are enabled (-O or PYTHONOPTIMIZE=1), and the application includes a handler that uses the Request.post() method, then an attacker may be able to execute a DoS attack with a specially crafted message. This issue is fixed in version 3.13.3.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a request to be crafted in such a way that an AIOHTTP server's memory fills up uncontrollably during processing. If an application includes a handler that uses the Request.post() method, an attacker may be able to freeze the server by exhausting the memory. This issue is fixed in version 3.13.3.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. In versions 3.13.2 and below, handling of chunked messages can result in excessive blocking CPU usage when receiving a large number of chunks. If an application makes use of the request.read() method in an endpoint, it may be possible for an attacker to cause the server to spend a moderate amount of blocking CPU time (e.g. 1 second) while processing the request. This could potentially lead to DoS as the server would be unable to handle other requests during that time. This issue is fixed in version 3.13.3.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()There exists a kernel oops caused by a BUG_ON(nhead < 0) atnet/core/skbuff.c:2232 in pskb_expand_head().This bug is triggered as part of the calipso_skbuff_setattr()routine when skb_cow() is passed headroom > INT_MAX(i.e. (int)(skb_headroom(skb) + len_delta) < 0).The root cause of the bug is due to an implicit integer cast in__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensurethat delta = headroom - skb_headroom(skb) is never negative, otherwisewe will trigger a BUG_ON in pskb_expand_head(). However, ifheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, deltabecomes negative, and pskb_expand_head() is passed a negative value fornhead.Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()by only using skb_cow() to grow headroom.PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verfA zero length gss_token results in pages == 0 and in_token->pages[0]is NULL. The code unconditionally evaluatespage_address(in_token->pages[0]) for the initial memcpy, which candereference NULL even when the copy length is 0. Guard the firstmemcpy so it only runs when length > 0.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).
-
Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.2, a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. This vulnerability is fixed in 0.6.2.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-pyasn1 > 0-0 (version in image is 0.4.2-150000.3.8.1).
-
Description: pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-PyJWT > 0-0 (version in image is 2.4.0-150200.3.8.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921e: fix rmmod crash in driver reload testIn insmod/rmmod stress test, the following crash dump shows up immediately.The problem is caused by missing mt76_dev in mt7921_pci_remove(). Weshould make sure the drvdata is ready before probe() finished.[168.862789] ==================================================================[168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480[168.862805] Write of size 8 at addr 0000000000006df0 by task rmmod/5361[168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G OE 5.19.0-rc6 #1[168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020[168.862820] Call Trace:[168.862822] [168.862825] dump_stack_lvl+0x49/0x63[168.862832] print_report.cold+0x493/0x6b7[168.862845] kasan_report+0xa7/0x120[168.862857] kasan_check_range+0x163/0x200[168.862861] __kasan_check_write+0x14/0x20[168.862866] try_to_grab_pending+0x59/0x480[168.862870] __cancel_work_timer+0xbb/0x340[168.862898] cancel_work_sync+0x10/0x20[168.862902] mt7921_pci_remove+0x61/0x1c0 [mt7921e][168.862909] pci_device_remove+0xa3/0x1d0[168.862914] device_remove+0xc4/0x170[168.862920] device_release_driver_internal+0x163/0x300[168.862925] driver_detach+0xc7/0x1a0[168.862930] bus_remove_driver+0xeb/0x2d0[168.862935] driver_unregister+0x71/0xb0[168.862939] pci_unregister_driver+0x30/0x230[168.862944] mt7921_pci_driver_exit+0x10/0x1b [mt7921e][168.862949] __x64_sys_delete_module+0x2f9/0x4b0[168.862968] do_syscall_64+0x38/0x90[168.862973] entry_SYSCALL_64_after_hwframe+0x63/0xcdTest steps:1. insmode2. do not ifup3. rmmod quickly (within 1 second)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Prevent recovery work from being queued during device removalUse disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()to ensure that no new recovery work items can be queued after deviceremoval has started. Previously, recovery work could be scheduled evenafter canceling existing work, potentially leading to use-after-freebugs if recovery accessed freed resources.Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to betterreflect its new behavior.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_mon_reinit_self().syzbot reported use-after-free of tipc_net(net)->monitors[]in tipc_mon_reinit_self(). [0]The array is protected by RTNL, but tipc_mon_reinit_self()iterates over it without RTNL.tipc_mon_reinit_self() is called from tipc_net_finalize(),which is always under RTNL except for tipc_net_finalize_work().Let's hold RTNL in tipc_net_finalize_work().[0]:BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Workqueue: events tipc_net_finalize_workCall 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 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Prevent potential UAF in group creationThis commit prevents the possibility of a use after free issue in theGROUP_CREATE ioctl function, which arose as pointer to the group isaccessed in that ioctl function after storing it in the Xarray.A malicious userspace can second guess the handle of a group and tryto call GROUP_DESTROY ioctl from another thread around the same timeas GROUP_CREATE ioctl.To prevent the use after free exploit, this commit uses a mark on anentry of group pool Xarray which is added just before returning fromthe GROUP_CREATE ioctl function. The mark is checked for all ioctlsthat specify the group handle and so userspace won't be abe to deletea group that isn't marked yet.v2: Add R-bs and fixes tags
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: fsl-usb: Fix use-after-free in delayed work during device removalThe delayed work item otg_event is initialized in fsl_otg_conf() andscheduled under two conditions:1. When a host controller binds to the OTG controller.2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via fsl_otg_remove():the fsl_otg instance may be freed while the delayed work is still pendingor executing. This leads to use-after-free when the work functionfsl_otg_event() accesses the already freed memory.The problematic scenario:(detach thread) | (delayed work)fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove()before deallocating the fsl_otg structure. This ensures the delayed workis properly canceled and completes execution prior to memory deallocation.This bug was identified through static analysis.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add VLAN id validation before usingCurrently, the VLAN id may be used without validation whenreceive a VLAN configuration mailbox from VF. The length ofvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may causeout-of-bounds memory access once the VLAN id is bigger thanor equal to VLAN_N_VID.Therefore, VLAN id needs to be checked to ensure it is withinthe range of VLAN_N_VID.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erspan: Initialize options_len before referencing options.The struct ip_tunnel_info has a flexible array member namedoptions that is protected by a counted_by(options_len)attribute.The compiler will use this information to enforce runtime boundschecking deployed by FORTIFY_SOURCE string helpers.As laid out in the GCC documentation, the counter must beinitialized before the first reference to the flexible arraymember.After scanning through the files that use struct ip_tunnel_infoand also refer to options or options_len, it appears the normalcase is to use the ip_tunnel_info_opts_set() helper.Said helper would initialize options_len properly before copyingdata into options, however in the GRE ERSPAN code a partialupdate is done, preventing the use of the helper function.Before this change the handling of ERSPAN traffic in GRE tunnelswould cause a kernel panic when the kernel is compiled withGCC 15+ and having FORTIFY_SOURCE configured:memcpy: detected buffer overflow: 4 byte write of buffer size 0Call Trace: __fortify_panic+0xd/0xf erspan_rcv.cold+0x68/0x83 ? ip_route_input_slow+0x816/0x9d0 gre_rcv+0x1b2/0x1c0 gre_rcv+0x8e/0x100 ? raw_v4_input+0x2a0/0x2b0 ip_protocol_deliver_rcu+0x1ea/0x210 ip_local_deliver_finish+0x86/0x110 ip_local_deliver+0x65/0x110 ? ip_rcv_finish_core+0xd6/0x360 ip_rcv+0x186/0x1a0Reported-at: https://launchpad.net/bugs/2129580
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Crypt::Sodium::XS module versions prior to 0.000042, for Perl, include a vulnerable version of libsodiumlibsodium <= 1.0.20 or a version of libsodium released before December 30, 2025 contains a vulnerability documented as CVE-2025-69277 https://www.cve.org/CVERecord?id=CVE-2025-69277 .The libsodium vulnerability states:In atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.0.000042 includes a version of libsodium updated to 1.0.20-stable, released January 3, 2026, which includes a fix for the vulnerability.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsodium23 > 0-0 (version in image is 1.0.18-150000.4.11.1).
-
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:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libldap-2_4-2 > 0-0 (version in image is 2.4.46-150600.23.21).
-
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpng16-16 > 0-0 (version in image is 1.6.40-150600.3.6.1).
-
Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).
-
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libtasn1 > 0-0 (version in image is 4.13-150000.4.14.1).
-
Description: The CNI portmap plugin allows containers to emulate opening a host port, forwarding that traffic to the container. Versions 1.6.0 through 1.8.0 inadvertently forward all traffic with the same destination port as the host port when the portmap plugin is configured with the nftables backend, thus ignoring the destination IP. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node. Containers that request HostPort forwarding can intercept all traffic destined for that port. This requires that the portmap plugin be explicitly configured to use the nftables backend. This issue is fixed in version 1.9.0. To workaround, configure the portmap plugin to use the iptables backend. It does not have this vulnerability.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: skip lock-range check on equal size to avoid size==0 underflowWhen size equals the current i_size (including 0), the code used to callcheck_lock_range(filp, i_size, size - 1, WRITE), which computes `size - 1`and can underflow for size==0. Skip the equal case.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix buffer validation by including null terminator size in EA lengthThe smb2_set_ea function, which handles Extended Attributes (EA),was performing buffer validation checks that incorrectly omitted the sizeof the null terminating character (+1 byte) for EA Name.This patch fixes the issue by explicitly adding '+ 1' to EaNameLength wherethe null terminator is expected to be present in the buffer, ensuringthe validation accurately reflects the total required buffer size.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).
-
Description: User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150600.15.12.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150600.15.12.1).
-
Description: 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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix UAF race between device unplug and FW event processingThe function panthor_fw_unplug() will free the FW memory sections.The problem is that there could still be pending FW events which are yetnot handled at this point. process_fw_events_work() can in this case tryto access said freed memory.Simply call disable_work_sync() to both drain and prevent futureinvocation of process_fw_events_work().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: lkkbd - disable pending work before freeing devicelkkbd_interrupt() schedules lk->tq via schedule_work(), and the workhandler lkkbd_reinit() dereferences the lkkbd structure and itsserio/input_dev fields.lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbdstructure without preventing the reinit work from being queued againuntil serio_close() returns. This can allow the work handler to runafter the structure has been freed, leading to a potential use-after-free.Use disable_work_sync() instead of cancel_work_sync() to ensure thereinit work cannot be re-queued, and call it both in lkkbd_disconnect()and in lkkbd_connect() error paths after serio_open().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl > 0-0 (version in image is 8.14.1-150700.7.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make decode_pool() more resilient against corrupted osdmapsIf the osdmap is (maliciously) corrupted such that the encoded lengthof ceph_pg_pool envelope is less than what is expected for a particularencoding version, out-of-bounds reads may ensue because the only boundscheck that is there is based on that length value.This patch adds explicit bounds checks for each field that is decodedor skipped.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.
Packages affected:
- sle-module-server-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- util-linux > 0-0 (version in image is 2.40.4-150700.4.3.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix general protection fault in __smc_diag_dumpThe syzbot report a crash: Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f] CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline] RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89 Call Trace: smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217 smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234 netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327 __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442 netlink_dump_start include/linux/netlink.h:341 [inline] smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251 __sock_diag_cmd net/core/sock_diag.c:249 [inline] sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg net/socket.c:729 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2614 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668 __sys_sendmsg+0x16d/0x220 net/socket.c:2700 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The process like this: (CPU1) | (CPU2) ---------------------------------|------------------------------- inet_create() | // init clcsock to NULL | sk = sk_alloc() | | // unexpectedly change clcsock | inet_init_csk_locks() | | // add sk to hash table | smc_inet_init_sock() | smc_sk_init() | smc_hash_sk() | | // traverse the hash table | smc_diag_dump_proto | __smc_diag_dump() | // visit wrong clcsock | smc_diag_msg_common_fill() // alloc clcsock | smc_create_clcsk | sock_create_kern |With CONFIG_DEBUG_LOCK_ALLOC=y, the smc->clcsock is unexpectedly changedin inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc,just remove it.After removing the INET_PROTOSW_ICSK flag, this patch alse revertcommit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC")to avoid casting smc_sock to inet_connection_sock.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:via_wdt: fix critical boot hang due to unnamed resource allocationThe VIA watchdog driver uses allocate_resource() to reserve a MMIOregion for the watchdog control register. However, the allocatedresource was not given a name, which causes the kernel resource treeto contain an entry marked as "" under /proc/iomem on x86platforms.During boot, this unnamed resource can lead to a critical hang becausesubsequent resource lookups and conflict checks fail to handle theinvalid entry properly.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sock: fix hardened usercopy panic in sock_recv_errqueueskbuff_fclone_cache was created without defining a usercopy region,[1] unlike skbuff_head_cache which properly whitelists the cb[] field.[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY isenabled and the kernel attempts to copy sk_buff.cb data to userspacevia sock_recv_errqueue() -> put_cmsg().The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1]2. The skb is cloned via skb_clone() using the pre-allocated fclone[3] 3. The cloned skb is queued to sk_error_queue for timestampreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5]When cloned skbs allocated from skbuff_fclone_cache are used in thesocket error queue, accessing the sock_exterr_skb structure in skb->cbvia put_cmsg() triggers a usercopy hardening violation:[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)![ 5.382796] kernel BUG at mm/usercopy.c:102![ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI[ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7[ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80[ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490[ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246[ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74[ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0[ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74[ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001[ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00[ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000[ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0[ 5.384903] PKRU: 55555554[ 5.384903] Call Trace:[ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0[ 5.384903] __check_object_size+0x46c/0x690[ 5.384903] put_cmsg+0x129/0x5e0[ 5.384903] sock_recv_errqueue+0x22f/0x380[ 5.384903] tls_sw_recvmsg+0x7ed/0x1960[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? schedule+0x6d/0x270[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? mutex_unlock+0x81/0xd0[ 5.384903] ? __pfx_mutex_unlock+0x10/0x10[ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10[ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0[ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix improper freeing of purex itemIn qla2xxx_process_purls_iocb(), an item is allocated viaqla27xx_copy_multiple_pkt(), which internally callsqla24xx_alloc_purex_item().The qla24xx_alloc_purex_item() function may return a pre-allocated itemfrom a per-adapter pool for small allocations, instead of dynamicallyallocating memory with kzalloc().An error handling path in qla2xxx_process_purls_iocb() incorrectly useskfree() to release the item. If the item was from the pre-allocatedpool, calling kfree() on it is a bug that can lead to memory corruption.Fix this by using the correct deallocation function,qla24xx_free_purex_item(), which properly handles both dynamicallyallocated and pre-allocated items.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: cloud-init through 25.1.2 includes the systemd socket unit cloud-init-hotplugd.socket with default SocketMode that grants 0666 permissions, making it world-writable. This is used for the "/run/cloud-init/hook-hotplug-cmd" FIFO. An unprivileged user could trigger hotplug-hook commands.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: In 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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.12.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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: ipc: fix use-after-free in ipc_msg_send_requestipc_msg_send_request() waits for a generic netlink reply using anipc_msg_table_entry on the stack. The generic netlink handler(handle_generic_event()/handle_response()) fills entry->response underipc_msg_table_lock, but ipc_msg_send_request() used to validate and freeentry->response without holding the same lock.Under high concurrency this allows a race where handle_response() iscopying data into entry->response while ipc_msg_send_request() has justfreed it, leading to a slab-use-after-free reported by KASAN inhandle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]Fix by:- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table.- Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock.- Returning NULL in the error path, preserving the original API semantics.This makes all accesses to entry->response consistent withhandle_response(), which already updates and fills the response bufferunder ipc_msg_table_lock, and closes the race that allowed the UAF.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix admin request_queue lifetimeThe namespaces can access the controller's admin request_queue, andstale references on the namespaces may exist after tearing down thecontroller. Ensure the admin request_queue is active by moving thecontroller's 'put' to after all controller references have been releasedto ensure no one is can access the request_queue. This fixes a reporteduse-after-free bug: BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scs: fix a wrong parameter in __scs_magic__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' isgiven. 'task_scs(tsk)' is the starting address of the task's shadow callstack, and '__scs_magic(task_scs(tsk))' is the end address of the task'sshadow call stack. Here should be '__scs_magic(task_scs(tsk))'.The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGEis enabled, the shadow call stack usage checking function(scs_check_usage) would scan an incorrect memory range. This could lead1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg.2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses).However, since this is purely a debugging feature(CONFIG_DEBUG_STACK_USAGE), normal production systems should be notunaffected. The bug only impacts developers and testers who are activelydebugging stack usage with this configuration enabled.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: hold region lock when flushing snapshotsNetdevsim triggers a splat on reload, when it destroys regionswith snapshots pending: WARNING: CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140 CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580 RIP: 0010:devlink_region_snapshot_del+0x12e/0x140 Call Trace: devl_region_destroy+0x70/0x140 nsim_dev_reload_down+0x2f/0x60 [netdevsim] devlink_reload+0x1f7/0x360 devlink_nl_cmd_reload+0x6ce/0x860 genl_family_rcv_msg_doit.isra.0+0x145/0x1c0This is the locking assert in devlink_region_snapshot_del(),we're supposed to be holding the region->snapshot_lock here.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: visconti: Fix memory leak in visconti_register_pll()@pll->rate_table has allocated memory by kmemdup(), if clk_hw_register()fails, it should be freed, otherwise it will cause memory leak issue,this patch fixes it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix memory leak of iter->temp when reading trace_pipekmemleak reports: unreferenced object 0xffff88814d14e200 (size 256): comm "cat", pid 336, jiffies 4294871818 (age 779.490s) hex dump (first 32 bytes): 04 00 01 03 00 00 00 00 08 00 00 00 00 00 00 00 ................ 0c d8 c8 9b ff ff ff ff 04 5a ca 9b ff ff ff ff .........Z...... backtrace: [] __kmalloc+0x4f/0x140 [] trace_find_next_entry+0xbb/0x1d0 [] trace_print_lat_context+0xaf/0x4e0 [] print_trace_line+0x3e0/0x950 [] tracing_read_pipe+0x2d9/0x5a0 [] vfs_read+0x143/0x520 [] ksys_read+0xbd/0x160 [] do_syscall_64+0x3f/0x90 [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8when reading file 'trace_pipe', 'iter->temp' is allocated or relocatedin trace_find_next_entry() but not freed before 'trace_pipe' is closed.To fix it, free 'iter->temp' in tracing_release_pipe().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Disable works on hci_unregister_devThis make use of disable_work_* on hci_unregister_dev since the hci_dev isabout to be freed new submissions are not disarable.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc > 0-0 (version in image is 2.38-150600.14.37.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu: Clear iommu-dma ops on cleanupIf iommu_device_register() encounters an error, it can end up tearingdown already-configured groups and default domains, however thiscurrently still leaves devices hooked up to iommu-dma (and evenhistorically the behaviour in this area was at best inconsistent acrossarchitectures/drivers...) Although in the case that an IOMMU is presentwhose driver has failed to probe, users cannot necessarily expect DMA towork anyway, it's still arguable that we should do our best to putthings back as if the IOMMU driver was never there at all, and certainlythe potential for crashing in iommu-dma itself is undesirable. Make surewe clean up the dev->dma_iommu flag along with everything else.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix WARN_ON(!ctx) in __free_event() for partial initMove the get_ctx(child_ctx) call and the child_event->ctx assignment tooccur immediately after the child event is allocated. Ensure thatchild_event->ctx is non-NULL before any subsequent error path withininherit_event calls free_event(), satisfying the assumptions of thecleanup code.Details:There's no clear Fixes tag, because this bug is a side-effect ofmultiple interacting commits over time (up to 15 years old), nota single regression.The code initially incremented refcount then assigned contextimmediately after the child_event was created. Later, an earlyvalidity check for child_event was added before therefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check wasadded, assuming event->ctx is valid if the pmu_ctx is valid.The problem is that the WARN_ON_ONCE() could trigger after the initialcheck passed but before child_event->ctx was assigned, violating itsprecondition. The solution is to assign child_event->ctx right afterits initial validation. This ensures the context exists for anysubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().To resolve it, defer the refcount update and child_event->ctx assignmentdirectly after child_event->pmu_ctx is set but before checking if theparent event is orphaned. The cleanup routine depends onevent->pmu_ctx being non-NULL before it verifies event->ctx isnon-NULL. This also maintains the author's original intent of passingin child_ctx to find_get_pmu_context before its refcount/assignment.[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Disable iocc if dma-coherent property isn't setIf dma-coherent property isn't set then descriptors are non-cacheableand the iocc shareability bits should be disabled. Without this UFS canend up in an incompatible configuration and suffer from random cacherelated stability issues.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let's call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won't see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: debugfs: Fix legacy mode page table dump logicIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTRmaybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490...Avoid walking the page table if TT is not 00b or 01b.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Check GuC running state before deregistering exec queueIn normal operation, a registered exec queue is disabled andderegistered through the GuC, and freed only after the GuC confirmscompletion. However, if the driver is forced to unbind while the execqueue is still running, the user may call exec_destroy() after the GuChas already been stopped and CT communication disabled.In this case, the driver cannot receive a response from the GuC,preventing proper cleanup of exec queue resources. Fix this by directlyreleasing the resources when GuC is not running.Here is the failure dmesg log:"[ 468.089581] ---[ end trace 0000000000000000 ]---[ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)[ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535[ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1[ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)[ 468.092716] ------------[ cut here ]------------[ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]"v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration.(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNPWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UCvia a forced variable MTRR range.In most KVM-based setups, legacy devices such as the HPET and TPM areenumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, andoptionally a SystemMemory descriptor for an OperationRegion, e.g. if thedevice needs to be accessed via a Control Method.If a SystemMemory entry is present, then the kernel's ACPI driver willauto-ioremap the region so that it can be accessed at will. However, theACPI spec doesn't provide a way to enumerate the memory type ofSystemMemory regions, i.e. there's no way to tell software that a regionmust be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver alwaysmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.The dedicated device drivers however, e.g. the HPET driver and TPM driver,want to map their associated memory as UC or WC, as accessing PCI devicesusing WB is unsupported.On bare metal and non-CoCO, the conflicting requirements "work" as firmwareconfigures the PCI hole (and other device memory) to be UC in the MTRRs.So even though the ACPI mappings request WB, they are forced to UC- in thekernel's tracking due to the kernel properly handling the MTRR overrides,and thus are compatible with the drivers' requested WC/UC-.With force WB MTRRs on SNP and TDX guests, the ACPI mappings get theirrequested WB if the ACPI mappings are established before the dedicateddriver code attempts to initialize the device. E.g. if acpi_init()runs before the corresponding device driver is probed, ACPI's WB mappingwill "win", and result in the driver's ioremap() failing because theexisting WB mapping isn't compatible with the requested WC/UC-.E.g. when a TPM is emulated by the hypervisor (ignoring the securityimplications of relying on what is allegedly an untrusted entity to storemeasurements), the TPM driver will request UC and fail: [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12Note, the '0x2' and '0x0' values refer to "enum page_cache_mode", not x86'smemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).E.g. tracing mapping requests for TPM TIS yields: Mapping TPM TIS with req_type = 0 WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 Modules linked in: CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460 __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Revert "ipmi: fix msg stack when IPMI is disconnected"This reverts commit c608966f3f9c2dca596967501d00753282b395fc.This patch has a subtle bug that can cause the IPMI driver to go into aninfinite loop if the BMC misbehaves in a certain way. Apparentlycertain BMCs do misbehave this way because several reports have come inrecently about this.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() pathsThe usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()path is very broken.sys_prlimit64() does get_task_struct(tsk) but this only protects task_structitself. If tsk != current and tsk is not a leader, this process can exit/execand task_lock(tsk->group_leader) may use the already freed task_struct.Another problem is that sys_prlimit64() can race with mt-exec which changes->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)->group_leader may change between task_lock() and task_unlock().Change sys_prlimit64() to take tasklist_lock when necessary. This is notnice, but I don't see a better fix for -stable.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix IPsec cleanup over MPV deviceWhen we do mlx5e_detach_netdev() we eventually disable blocking eventsnotifier, among those events are IPsec MPV events from IB to core.So before disabling those blocking events, make sure to also unregisterthe devcom device and mark all this device operations as complete,in order to prevent the other device from using invalid netdevduring future devcom events which could cause the trace below.BUG: kernel NULL pointer dereference, address: 0000000000000010PGD 146427067 P4D 146427067 PUD 146488067 PMD 0Oops: Oops: 0000 [#1] SMPCPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1Tainted: [W]=WARNHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core] mlx5_devcom_send_event+0x8c/0x170 [mlx5_core] blocking_event+0x17b/0x230 [mlx5_core] notifier_call_chain+0x35/0xa0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core] mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib] mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib] ? idr_alloc_cyclic+0x50/0xb0 ? __kmalloc_cache_noprof+0x167/0x340 ? __kmalloc_noprof+0x1a7/0x430 __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe9/0x310 [mlx5_ib] ? kernfs_add_one+0x107/0x150 ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] auxiliary_bus_probe+0x3e/0x90 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x62d/0x830 __auxiliary_device_add+0x3b/0xa0 ? auxiliary_device_init+0x41/0x90 add_adev+0xd1/0x150 [mlx5_core] mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core] esw_mode_change+0x6c/0xc0 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x180/0x2b0 ? devlink_get_from_attrs_lock+0x170/0x170 ? devlink_nl_eswitch_get_doit+0x290/0x290 ? devlink_nl_pre_doit_port_optional+0x50/0x50 ? genl_family_rcv_msg_dumpit+0xf0/0xf0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1fc/0x2d0 netlink_sendmsg+0x1e4/0x410 __sock_sendmsg+0x38/0x60 ? sockfd_lookup_light+0x12/0x60 __sys_sendto+0x105/0x160 ? __sys_recvmsg+0x4e/0x90 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f27bc91b13aCode: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clean up only new IRQ glue on request_irq() failureThe mlx5_irq_alloc() function can inadvertently free the entire rmapand end up in a crash[1] when the other threads tries to access this,when request_irq() fails due to exhausted IRQ vectors. This commitmodifies the cleanup to remove only the specific IRQ mapping that wasjust added.This prevents removal of other valid mappings and ensures precisecleanup of the failed IRQ allocation's associated glue object.Note: This error is observed when both fwctl and rds configs are enabled.[1]mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed torequest irq. err = -28infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 whiletrying to test write-combining supportmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed torequest irq. err = -28infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 whiletrying to test write-combining supportmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed torequest irq. err = -28mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed torequest irq. err = -28general protection fault, probably for non-canonical address0xe277a58fde16f291: 0000 [#1] SMP NOPTIRIP: 0010:free_irq_cpu_rmap+0x23/0x7dCall Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0RIP: 0033:0x7fc328603727Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b edff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000dRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000R13: 00000000000---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix a race in mptcp_pm_del_add_timer()mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)while another might have free entry already, as reported by syzbot.Add RCU protection to fix this issue.Also change confusing add_timer variable with stop_timer boolean.syzbot report:BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Workqueue: events mptcp_workerCall 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 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 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 Allocated by task 44: 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:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 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:245Freed by task 6630: 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:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Flush shmem writes before mapping buffers CPU-uncachedThe shmem layer zeroes out the new pages using cached mappings, and ifwe don't CPU-flush we might leave dirty cachelines behind, leading topotential data leaks and/or asynchronous buffer corruption when dirtycachelines are evicted.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Shutdown FW DMA in bnxt_shutdown()The netif_close() call in bnxt_shutdown() only stops packet DMA. Theremay be FW DMA for trace logging (recently added) that will continue. Ifwe kexec to a new kernel, the DMA will corrupt memory in the new kernel.Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW.This will stop the FW DMA. In case the call fails, call pcie_flr() toreset the function and stop the DMA.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sysfs: check visibility before changing group attribute ownershipSince commit 0c17270f9b92 ("net: sysfs: Implement is_visible forphys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() canhit WARN_ON() when trying to change owner of a file that isn't visible.See the trace below: WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30 [...] Call Trace: ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 ? sched_clock+0x10/0x30 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Fix this by checking is_visible() before trying to touch the attribute.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: enhance kfd process check in switch partitioncurrent switch partition only check if kfd_processes_table is empty.kfd_prcesses_table entry is deleted in kfd_process_notifier_release, butkfd_process tear down is in kfd_process_wq_release.consider two processes:Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node memberProcess B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw-> kfd_node tear down.Process A and B may trigger a race as shown in dmesg log.This patch is to resolve the race by adding an atomic kfd_process counterkfd_processes_count, it increment as create kfd process, decrement asfinish kfd_process_wq_release.v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pddsand bug fix. (Philip Yang)[3966658.307702] divide error: 0000 [#1] SMP NOPTI[3966658.350818] i10nm_edac[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu][3966658.362839] nfit[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu][3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00[3966658.380967] x86_pkg_temp_thermal[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[3966658.391536] PKRU: 55555554[3966658.391536] Call Trace:[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu][3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu][3966658.399754] intel_powerclamp[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu][3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu][3966658.410516] coretemp[3966658.434016] process_one_work+0x1ad/0x380[3966658.434021] worker_thread+0x49/0x310[3966658.438963] kvm_intel[3966658.446041] ? process_one_work+0x380/0x380[3966658.446045] kthread+0x118/0x140[3966658.446047] ? __kthread_bind_mask+0x60/0x60[3966658.446050] ret_from_fork+0x1f/0x30[3966658.446053] Modules linked in: kpatch_20765354(OEK)[3966658.455310] kvm[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)[3966658.473462] idxd_mdev[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:media: nxp: imx8-isi: Fix streaming cleanup on releaseThe current implementation unconditionally callsmxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This canlead to situations where any release call (like from a simple"v4l2-ctl -l") may release a currently streaming queue when called onsuch a device.This is reproducible on an i.MX8MP board by streaming from an ISIcapture device using gstreamer: gst-launch-1.0 -v v4l2src device=/dev/videoX ! \ video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \ fakesinkWhile this stream is running, querying the caps of the same deviceprovokes the error state: v4l2-ctl -l -d /dev/videoXThis results in the following trace:[ 155.452152] ------------[ cut here ]------------[ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6[ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT[ 157.064369] Hardware name: imx8mp_board_01 (DT)[ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi][ 157.087126] sp : ffff800080003ee0[ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000[ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50[ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000[ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000[ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000[ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38[ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000[ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000[ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200[ 157.161850] Call trace:[ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)[ 157.170319] __handle_irq_event_percpu+0x58/0x218[ 157.175029] handle_irq_event+0x54/0xb8[ 157.178867] handle_fasteoi_irq+0xac/0x248[ 157.182968] handle_irq_desc+0x48/0x68[ 157.186723] generic_handle_domain_irq+0x24/0x38[ 157.191346] gic_handle_irq+0x54/0x120[ 157.195098] call_on_irq_stack+0x24/0x30[ 157.199027] do_interrupt_handler+0x88/0x98[ 157.203212] el0_interrupt+0x44/0xc0[ 157.206792] __el0_irq_handler_common+0x18/0x28[ 157.211328] el0t_64_irq_handler+0x10/0x20[ 157.215429] el0t_64_irq+0x198/0x1a0[ 157.219009] ---[ end trace 0000000000000000 ]---Address this issue by moving the streaming preparation and cleanup tothe vb2 .prepare_streaming() and .unprepare_streaming() operations. Thisalso simplifies the driver by allowing direct usage of thevb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal ofthe manual cleanup from mxc_isi_video_release().
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Add devm release action to safely tear down CTWhen a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATEflag, the driver initiates TLB invalidation requests via the CTB mechanismwhile releasing the BO. However a premature release of the CTB BO can leadto system crashes, as observed in:Oops: Oops: 0000 [#1] SMP NOPTIRIP: 0010:h2g_write+0x2f3/0x7c0 [xe]Call Trace: guc_ct_send_locked+0x8b/0x670 [xe] xe_guc_ct_send_locked+0x19/0x60 [xe] send_tlb_invalidation+0xb4/0x460 [xe] xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe] ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe] ggtt_node_remove+0x110/0x140 [xe] xe_ggtt_node_remove+0x40/0xa0 [xe] xe_ggtt_remove_bo+0x87/0x250 [xe]Introduce a devm-managed release action during xe_guc_ct_init() andxe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement beforeresource deallocation, preventing the use-after-free scenario.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCERfor FW trace data type that has not been initialized. This will resultin a crash in bnxt_bs_trace_type_wrap(). Add a guard to check for avalid magic_byte pointer before proceeding.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix PTP cleanup on driver removal in error pathImprove the cleanup on releasing PTP resources in error path.The error case might happen either at the driver probe and PTPfeature initialization or on PTP restart (errors in reset handling, NVMupdate etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pffunction) and 'ps_lock' mutex deinitialization were missed.Additionally, ptp clock was not unregistered in the latter case.Keep PTP state as 'uninitialized' on init to distinguish between errorscenarios and to avoid resource release duplication at driver removal.The consequence of missing ice_ptp_cleanup_pf call is the following calltrace dumped when ice_adapter object is freed (port list is not empty,as it is required at this stage):[ T93022] ------------[ cut here ]------------[ T93022] WARNING: CPU: 10 PID: 93022 atice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice]...[ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice]...[ T93022] Call Trace:[ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c][ T93022] ? __warn.cold+0xb0/0x10e[ T93022] ? ice_adapter_put+0xef/0x100 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c][ T93022] ? report_bug+0xd8/0x150[ T93022] ? handle_bug+0xe9/0x110[ T93022] ? exc_invalid_op+0x17/0x70[ T93022] ? asm_exc_invalid_op+0x1a/0x20[ T93022] ? ice_adapter_put+0xef/0x100 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c][ T93022] pci_device_remove+0x42/0xb0[ T93022] device_release_driver_internal+0x19f/0x200[ T93022] driver_detach+0x48/0x90[ T93022] bus_remove_driver+0x70/0xf0[ T93022] pci_unregister_driver+0x42/0xb0[ T93022] ice_module_exit+0x10/0xdb0 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c]...[ T93022] ---[ end trace 0000000000000000 ]---[ T93022] ice: module unloaded
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150600.15.12.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix crash in process_v2_sparse_read() for encrypted directoriesThe crash in process_v2_sparse_read() for fscrypt-encrypted directorieshas been reported. Issue takes place for Ceph msgr2 protocol in securemode. It can be reproduced by the steps:sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure(1) mkdir /mnt/cephfs/fscrypt-test-3(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3(4) fscrypt lock /mnt/cephfs/fscrypt-test-3(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar(7) Issue has been triggered[ 408.072247] ------------[ cut here ]------------[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_commonintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discoverypmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypasspolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouseserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfgpata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.17.0-5.fc42 04/01/2014[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f88e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)knlGS:0000000000000000[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0[ 408.072336] PKRU: 55555554[ 408.072337] Call Trace:[ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10[ 408.072347] ? _raw_spin_unlock+0xe/0x40[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830[ 408.072353] ? __kasan_check_write+0x14/0x30[ 408.072357] ? mutex_lock+0x84/0xe0[ 408.072359] ? __pfx_mutex_lock+0x10/0x10[ 408.072361] ceph_con_workfn+0x27e/0x10e0[ 408.072364] ? metric_delayed_work+0x311/0x2c50[ 408.072367] process_one_work+0x611/0xe20[ 408.072371] ? __kasan_check_write+0x14/0x30[ 408.072373] worker_thread+0x7e3/0x1580[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 408.072378] ? __pfx_worker_thread+0x10/0x10[ 408.072381] kthread+0x381/0x7a0[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10[ 408.072385] ? __pfx_kthread+0x10/0x10[ 408.072387] ? __kasan_check_write+0x14/0x30[ 408.072389] ? recalc_sigpending+0x160/0x220[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50[ 408.072394] ? calculate_sigpending+0x78/0xb0[ 408.072395] ? __pfx_kthread+0x10/0x10[ 408.072397] ret_from_fork+0x2b6/0x380[ 408.072400] ? __pfx_kthread+0x10/0x10[ 408.072402] ret_from_fork_asm+0x1a/0x30[ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]---[ 408.072418] Oops: general protection fault, probably for non-canonicaladdress 0xdffffc00000000---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix rcu protection in md_wakeup_threadWe attempted to use RCU to protect the pointer 'thread', but directlypassed the value when calling md_wakeup_thread(). This means that theRCU pointer has been acquired before rcu_read_lock(), which rendersrcu_read_lock() ineffective and could lead to a use-after-free.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()Don't add BO to the vdev->bo_list in ivpu_gem_create_object().When failure happens inside drm_gem_shmem_create(), the BO is notfully created and ivpu_gem_bo_free() callback will not be calledcausing a deleted BO to be left on the list.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix return value of f2fs_recover_fsync_data()With below scripts, it will trigger panic in f2fs:mkfs.f2fs -f /dev/vddmount /dev/vdd /mnt/f2fstouch /mnt/f2fs/foosyncecho 111 >> /mnt/f2fs/foof2fs_io fsync /mnt/f2fs/foof2fs_io shutdown 2 /mnt/f2fsumount /mnt/f2fsmount -o ro,norecovery /dev/vdd /mnt/f2fsormount -o ro,disable_roll_forward /dev/vdd /mnt/f2fsF2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361fF2FS-fs (vdd): Stopped filesystem due to reason: 0F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1Filesystem f2fs get_tree() didn't set fc->root, returned 1------------[ cut here ]------------kernel BUG at fs/super.c:1761!Oops: invalid opcode: 0000 [#1] SMP PTICPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vfs_get_tree.cold+0x18/0x1aCall Trace: fc_mount+0x13/0xa0 path_mount+0x34e/0xc50 __x64_sys_mount+0x121/0x150 do_syscall_64+0x84/0x800 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fa6cc126cfeThe root cause is we missed to handle error number returned fromf2fs_recover_fsync_data() when mounting image w/ ro,norecovery orro,disable_roll_forward mount option, result in returning a positiveerror number to vfs_get_tree(), fix it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix kernel BUG in ocfs2_find_victim_chainsyzbot reported a kernel BUG in ocfs2_find_victim_chain() because the`cl_next_free_rec` field of the allocation chain list (next free slot inthe chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)condition in ocfs2_find_victim_chain() and panicking the kernel.To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),just before calling ocfs2_find_victim_chain(), the code block in it beingexecuted when either of the following conditions is true:1. `cl_next_free_rec` is equal to 0, indicating that there are no freechains in the allocation chain list2. `cl_next_free_rec` is greater than `cl_count` (the total number ofchains in the allocation chain list)Either of them being true is indicative of the fact that there are nochains left for usage.This is addressed using ocfs2_error(), which printsthe error log for debugging purposes, rather than panicking the kernel.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix memory leak in nr_sendmsg()syzbot reported a memory leak [1].When function sock_alloc_send_skb() return NULL in nr_output(), theoriginal skb is not freed, which was allocated in nr_sendmsg(). Fix thisby freeing it before return.[1]BUG: memory leakunreferenced object 0xffff888129f35500 (size 240): comm "syz.0.17", pid 6119, jiffies 4294944652 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(.... backtrace (crc 1456a3e4): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4983 [inline] slab_alloc_node mm/slub.c:5288 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671 sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965 sock_alloc_send_skb include/net/sock.h:1859 [inline] nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x293/0x2a0 net/socket.c:1195 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0x143/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating zero-sized extent in extent cacheAs syzbot reported:F2FS-fs (loop0): __update_extent_tree_range: extent len is zero, type: 0, extent [0, 0, 0], age [0, 0]------------[ cut here ]------------kernel BUG at fs/f2fs/extent_cache.c:678!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678Call Trace: f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085 f2fs_do_zero_range fs/f2fs/file.c:1657 [inline] f2fs_zero_range+0x10c1/0x1580 fs/f2fs/file.c:1737 f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030 vfs_fallocate+0x669/0x7e0 fs/open.c:342 ioctl_preallocate fs/ioctl.c:289 [inline] file_ioctl+0x611/0x780 fs/ioctl.c:-1 do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576 __do_sys_ioctl fs/ioctl.c:595 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f07bc58eec9In error path of f2fs_zero_range(), it may add a zero-sized extentinto extent cache, it should be avoided.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: vfs: fix race on m_flags in vfs_cacheksmbd maintains delete-on-close and pending-delete state inksmbd_inode->m_flags. In vfs_cache.c this field is accessed underinconsistent locking: some paths read and modify m_flags underci->m_lock while others do so without taking the lock at all.Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock.This creates a potential data race on m_flags when multiple threadsopen, close and delete the same file concurrently. In the worst casedelete-on-close and pending-delete bits can be lost or observed in aninconsistent state, leading to confusing delete semantics (files thatstay on disk after delete-on-close, or files that disappear while stillin use).Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock.This unifies the locking around m_flags and removes the data race whilepreserving the existing delete-on-close behaviour.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslotReject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that wasinitially created with a guest_memfd binding, as KVM doesn't supporttoggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enablingKVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.Failure to reject the new memslot results in a use-after-free due to KVMnot unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLYchange is easy enough, and can/will be done as a hardening measure (inanticipation of KVM supporting dirty logging on guest_memfd at some point),but fixing the use-after-free would only address the immediate symptom. ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745 CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5c0 kasan_report+0xb4/0xe0 kvm_gmem_release+0x362/0x400 [kvm] __fput+0x2fa/0x9d0 task_work_run+0x12c/0x200 do_exit+0x6ae/0x2100 do_group_exit+0xa8/0x230 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0x737/0x740 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 Allocated by task 745 on cpu 6 at 9.746971s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_kmalloc+0x77/0x90 kvm_set_memory_region.part.0+0x652/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 745 on cpu 6 at 9.747467s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x3b/0x60 kfree+0xf5/0x440 kvm_set_memslot+0x3c2/0x1160 [kvm] kvm_set_memory_region.part.0+0x86a/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ublk: fix deadlock when reading partition tableWhen one process(such as udev) opens ublk block device (e.g., to readthe partition table via bdev_open()), a deadlock[1] can occur:1. bdev_open() grabs disk->open_mutex2. The process issues read I/O to ublk backend to read partition table3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation)5. This eventually calls blkdev_release() from the same context6. blkdev_release() tries to grab disk->open_mutex again7. Deadlock: same task waiting for a mutex it already holdsThe fix is to run blk_update_request() and blk_mq_end_request() with bottomhalves disabled. This forces blkdev_release() to run in kernel work-queuecontext instead of current task work context, and allows ublk server to makeforward progress, and avoids the deadlock.[axboe: rewrite comment in ublk]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Always remove class from active list before deleting in ets_qdisc_changezdi-disclosures@trendmicro.com says:The vulnerability is a race condition between `ets_qdisc_dequeue` and`ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.Attacker requires the capability to create new user and network namespacein order to trigger the bug.See my additional commentary at the end of the analysis.Analysis:static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack){... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc); } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0;}Comment:This happens because some of the classes have their qdiscs assigned toNULL, but remain in the active list. This commit fixes this issue by alwaysremoving the class from the active list before deleting and freeing itsassociated qdiscReproducer Steps(trimmed version of what was sent by zdi-disclosures@trendmicro.com)```DEV="${DEV:-lo}"ROOT_HANDLE="${ROOT_HANDLE:-1:}"BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2PING_BYTES="${PING_BYTES:-48}"PING_COUNT="${PING_COUNT:-200000}"PING_DST="${PING_DST:-127.0.0.1}"SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null}trap cleanup EXITip link set "$DEV" uptc qdisc del dev "$DEV" root 2>/dev/null || truetc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2tc -s qdisc ls dev $DEVping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 &tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc -s qdisc ls dev $DEVtc qdisc del dev "$DEV" parent ---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs: set dummy blocksize to read boot_block when mountingWhen mounting, sb->s_blocksize is used to read the boot_block withoutbeing defined or validated. Set a dummy blocksize before attempting toread the boot_block.The issue can be triggered with the following syz reproducer: mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)Here, the ioctl sets the bdev block size to 16384. During mount,get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leavessb->s_blocksize at zero.Later, ntfs_init_from_boot() attempts to read the boot_block whilesb->s_blocksize is still zero, which triggers the bug.[almaz.alexandrovich@paragon-software.com: changed comment style, addedreturn value handling]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: invalidate dentry cache on failed whiteout creationF2FS can mount filesystems with corrupted directory depth values thatget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUToperations are performed on such directories, f2fs_rename performsdirectory modifications (updating target entry and deleting sourceentry) before attempting to add the whiteout entry via f2fs_add_link.If f2fs_add_link fails due to the corrupted directory structure, thefunction returns an error to VFS, but the partial directorymodifications have already been committed to disk. VFS assumes theentire rename operation failed and does not update the dentry cache,leaving stale mappings.In the error path, VFS does not call d_move() to update the dentrycache. This results in new_dentry still pointing to the old inode(new_inode) which has already had its i_nlink decremented to zero.The stale cache causes subsequent operations to incorrectly referencethe freed inode.This causes subsequent operations to use cached dentry information thatno longer matches the on-disk state. When a second rename targets thesame entry, VFS attempts to decrement i_nlink on the stale inode, whichmay already have i_nlink=0, triggering a WARNING in drop_nlink().Example sequence:1. First rename (RENAME_WHITEOUT): file2 -> file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 -> inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)2. Second rename: file3 -> file1 - VFS uses stale cache: file1 -> inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()Fix this by explicitly invalidating old_dentry and new_dentry whenf2fs_add_link fails during whiteout creation. This forces VFS torefresh from disk on subsequent operations, ensuring cache consistencyeven when the rename partially succeeds.Reproducer:1. Mount F2FS image with corrupted i_current_depth2. renameat2(file2, file1, RENAME_WHITEOUT)3. renameat2(file3, file1, 0)4. System triggers WARNING in drop_nlink()
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: use global inline_xattr_slab instead of per-sb slab cacheAs Hong Yun reported in mailing list:loop7: detected capacity change from 0 to 131072------------[ cut here ]------------kmem_cache of name 'f2fs_xattr_entry-7:7' already existsWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307Call Trace: __kmem_cache_create include/linux/slab.h:353 [inline] f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline] f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692 vfs_get_tree+0x43/0x140 fs/super.c:1815 do_new_mount+0x201/0x550 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe bug can be reproduced w/ below scripts:- mount /dev/vdb /mnt1- mount /dev/vdc /mnt2- umount /mnt1- mounnt /dev/vdb /mnt1The reason is if we created two slab caches, named f2fs_xattr_entry-7:3and f2fs_xattr_entry-7:7, and they have the same slab size. Actually,slab system will only create one slab cache core structure which hasslab name of "f2fs_xattr_entry-7:3", and two slab caches share the samestructure and cache address.So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it willdecrease reference count of slab cache, rather than release slab cacheentirely, since there is one more user has referenced the cache.Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again,slab system will find that there is existed cache which has the same nameand trigger the warning.Let's changes to use global inline_xattr_slab instead of per-sb slab cachefor fixing.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Do not reprogram affinitiy on ASP chipThe ASP chip is a very old variant of the GSP chip and is used e.g. inHP 730 workstations. When trying to reprogram the affinity it will crashwith a HPMC as the relevant registers don't seem to be at the usuallocation. Let's avoid the crash by checking the sversion. Also note,that reprogramming isn't necessary either, as the HP730 is a just asingle-CPU machine.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: avoid deadlock on fallback while reinjectingJakub reported an MPTCP deadlock at fallback time: WARNING: possible recursive locking detected 6.18.0-rc7-virtme #1 Not tainted -------------------------------------------- mptcp_connect/20858 is trying to acquire lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280 but task is already holding lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&msk->fallback_lock); lock(&msk->fallback_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by mptcp_connect/20858: #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0 #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0 #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 stack backtrace: CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full) Hardware name: Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0x6f/0xa0 print_deadlock_bug.cold+0xc0/0xcd validate_chain+0x2ff/0x5f0 __lock_acquire+0x34c/0x740 lock_acquire.part.0+0xbc/0x260 _raw_spin_lock_bh+0x38/0x50 __mptcp_try_fallback+0xd8/0x280 mptcp_sendmsg_frag+0x16c2/0x3050 __mptcp_retrans+0x421/0xaa0 mptcp_release_cb+0x5aa/0xa70 release_sock+0xab/0x1d0 mptcp_sendmsg+0xd5b/0x1bc0 sock_write_iter+0x281/0x4d0 new_sync_write+0x3c5/0x6f0 vfs_write+0x65e/0xbb0 ksys_write+0x17e/0x200 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fa5627cbc5e Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005 RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920 R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9cThe packet scheduler could attempt a reinjection after receiving anMP_FAIL and before the infinite map has been transmitted, causing adeadlock since MPTCP needs to do the reinjection atomically from WRTfallback.Address the issue explicitly avoiding the reinjection in the criticalscenario. Note that this is the only fallback critical section thatcould potentially send packets and hit the double-lock.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Discard Beacon frames to non-broadcast addressBeacon frames are required to be sent to the broadcast address, see IEEEStd 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frameshall be set to the broadcast address"). A unicast Beacon frame might beused as a targeted attack to get one of the associated STAs to dosomething (e.g., using CSA to move it to another channel). As such, itis better have strict filtering for this on the received side anddiscard all Beacon frames that are sent to an unexpected address.This is even more important for cases where beacon protection is used.The current implementation in mac80211 is correctly discarding unicastBeacon frames if the Protected Frame bit in the Frame Control field isset to 0. However, if that bit is set to 1, the logic used for checkingfor configured BIGTK(s) does not actually work. If the driver does nothave logic for dropping unicast Beacon frames with Protected Frame bit1, these frames would be accepted in mac80211 processing as valid Beaconframes even though they are not protected. This would allow beaconprotection to be bypassed. While the logic for checking beaconprotection could be extended to cover this corner case, a more genericcheck for discard all Beacon frames based on A1=unicast address coversthis without needing additional changes.Address all these issues by dropping received Beacon frames if they aresent to a non-broadcast address.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Sign extend kfunc call argumentsThe kfunc calls are native calls so they should follow LoongArch callingconventions. Sign extend its arguments properly to avoid kernel panic.This is done by adding a new emit_abi_ext() helper. The emit_abi_ext()helper performs extension in place meaning a value already store in thetarget register (Note: this is different from the existing sign_extend()helper and thus we can't reuse it).
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cpuset: fix warning when disabling remote partitionA warning was triggered as follows:WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110RIP: 0010:remote_partition_disable+0xf7/0x110RSP: 0018:ffffc90001947d88 EFLAGS: 00000206RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f55c8cd4887Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo "0-14" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo "0-14" > A1/A2/cpuset.cpus.exclusive # echo "root" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partitionWhen CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUsremain available for the top_cpuset, forcing partitions to share CPUs withthe top_cpuset. In this scenario, disabling the remote partition triggersa warning stating that effective_xcpus is not a subset ofsubpartitions_cpus. Partitions should be invalidated in this case toinform users that the partition is now invalid(cpus are shared withtop_cpuset).To fix this issue:1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus.2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:clk: samsung: exynos-clkout: Assign .num before accessing .hwsCommit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS)about the number of elements in .hws[], so that it can warn when .hws[]is accessed out of bounds. As noted in that change, the __counted_bymember must be initialized with the number of elements before the firstarray access happens, otherwise there will be a warning from each accessprior to the initialization because the number of elements is zero. Thisoccurs in exynos_clkout_probe() due to .num being assigned after .hws[]has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18 index 0 is out of range for type 'clk_hw *[*]'Move the .num initialization to before the first access of .hws[],clearing up the warning.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers is calculated and truncated into a 32-bit integer. A pointer to partially controlled data can then be written out of bounds.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsqlite3-0 > 0-0 (version in image is 3.50.2-150000.3.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix use-after-free caused by cyclic delayed workThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()to cancel the cyclic delayed work item ocelot->stats_work. However,cancel_delayed_work() may fail to cancel the work item if it is alreadyexecuting. While destroy_workqueue() does wait for all pending work itemsin the work queue to complete before destroying the work queue, it cannotprevent the delayed work item from being rescheduled within theocelot_check_stats_work() function. This limitation exists because thedelayed work item is only enqueued into the work queue after its timerexpires. Before the timer expiration, destroy_workqueue() has no visibilityof this pending work item. Once the work queue appears empty,destroy_workqueue() proceeds with destruction. When the timer eventuallyexpires, the delayed work item gets queued again, leading to the followingwarning:workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-statsWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0...RIP: 0010:__queue_work+0x875/0xaf0...RSP: 0018:ffff88806d108b10 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0Call Trace: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...The following diagram reveals the cause of the above warning:CPU 0 (remove) | CPU 1 (delayed work callback)mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAFThe above scenario actually constitutes a UAF vulnerability.The ocelot_stats_deinit() is only invoked when initializationfailure or resource destruction, so we must ensure that anydelayed work items cannot be rescheduled.Replace cancel_delayed_work() with disable_delayed_work_sync()to guarantee proper cancellation of the delayed work item andensure completion of any currently executing work before theworkqueue is deallocated.A deadlock concern was considered: ocelot_stats_deinit() is calledin a process context and is not holding any locks that the delayedwork item might also need. Therefore, the use of the _sync() variantis safe here.This bug was identified through static analysis. To reproduce theissue and validate the fix, I simulated ocelot-swit---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure no dirty metadata is written back for an fs with errors[BUG]During development of a minor feature (make sure all btrfs_bio::end_io()is called in task context), I noticed a crash in generic/388, wheremetadata writes triggered new works after btrfs_stop_all_workers().It turns out that it can even happen without any code modification, justusing RAID5 for metadata and the same workload from generic/388 is goingto trigger the use-after-free.[CAUSE]If btrfs hits an error, the fs is marked as error, no newtransaction is allowed thus metadata is in a frozen state.But there are some metadata modifications before that error, and they arestill in the btree inode page cache.Since there will be no real transaction commit, all those dirty foliosare just kept as is in the page cache, and they can not be invalidatedby invalidate_inode_pages2() call inside close_ctree(), because they aredirty.And finally after btrfs_stop_all_workers(), we call iput() on btreeinode, which triggers writeback of those dirty metadata.And if the fs is using RAID56 metadata, this will trigger RMW and queuenew works into rmw_workers, which is already stopped, causing warningfrom queue_work() and use-after-free.[FIX]Add a special handling for write_one_eb(), that if the fs is already inan error state, immediately mark the bbio as failure, instead of reallysubmitting them.Then during close_ctree(), iput() will just discard all those dirtytree blocks without really writing them back, thus no more new jobs foralready stopped-and-freed workqueues.The extra discard in write_one_eb() also acts as an extra safenet.E.g. the transaction abort is triggered by some extent/free spacetree corruptions, and since extent/free space tree is already corruptedsome tree blocks may be allocated where they shouldn't be (overwritingexisting tree blocks). In that case writing them back will furthercorrupting the fs.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to detect potential corrupted nid in free_nid_listAs reported, on-disk footer.ino and footer.nid is the same andout-of-range, let's add sanity check on f2fs_alloc_nid() to detectany potential corruption in free_nid_list.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Marshmallow is a lightweight library for converting complex objects to and from simple Python datatypes. In versions from 3.0.0rc1 to before 3.26.2 and from 4.0.0 to before 4.1.2, Schema.load(data, many=True) is vulnerable to denial of service attacks. A moderately sized request can consume a disproportionate amount of CPU time. This issue has been patched in version 3.26.2 and 4.1.2.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-marshmallow > 0-0 (version in image is 3.20.2-150400.9.10.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below contain parser logic which allows non-ASCII decimals to be present in the Range header. There is no known impact, but there is the possibility that there's a method to exploit a request smuggling vulnerability. This issue is fixed in version 3.13.3.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below enable an attacker to ascertain the existence of absolute path components through the path normalization logic for static files meant to prevent path traversal. If an application uses web.static() (not recommended for production deployments), it may be possible for an attacker to ascertain the existence of path components. This issue is fixed in version 3.13.3.
Packages affected:
- sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
- python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.1.1629-150500.20.38.1).
-
Description: Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glibc > 0-0 (version in image is 2.38-150600.14.37.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Fix synchronous external abort on unbindA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind isexecuted after the configuration sequence described above:modprobe usb_f_ecmmodprobe libcompositemodprobe configfscd /sys/kernel/config/usb_gadgetmkdir -p g1cd g1echo "0x1d6b" > idVendorecho "0x0104" > idProductmkdir -p strings/0x409echo "0123456789" > strings/0x409/serialnumberecho "Renesas." > strings/0x409/manufacturerecho "Ethernet Gadget" > strings/0x409/productmkdir -p functions/ecm.usb0mkdir -p configs/c.1mkdir -p configs/c.1/strings/0x409echo "ECM" > configs/c.1/strings/0x409/configurationif [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1fiecho 11e20000.usb > UDCecho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbindThe displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1The issue occurs because usbhs_sys_function_pullup(), which accesses the IPregisters, is executed after the USBHS clocks have been disabled. Theproblem is reproducible on the Renesas RZ/G3S SoC starting with theaddition of module stop in the clock enable/disable APIs. With module stopfunctionality enabled, a bus error is expected if a master accesses amodule whose clock has been stopped and module stop activated.Disable the IP clocks at the end of remove.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating compression context during writebackBai, Shuangpeng reported a bug as below:Oops: divide error: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857Call Trace: f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline] f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317 do_writepages+0x38e/0x640 mm/page-writeback.c:2634 filemap_fdatawrite_wbc mm/filemap.c:386 [inline] __filemap_fdatawrite_range mm/filemap.c:419 [inline] file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794 f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294 generic_write_sync include/linux/fs.h:3043 [inline] f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x7e9/0xe00 fs/read_write.c:686 ksys_write+0x19d/0x2d0 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe bug was triggered w/ below race condition:fsync setattr ioctl- f2fs_do_sync_file - file_write_and_wait_range - f2fs_write_cache_pages : inode is non-compressed : cc.cluster_size = F2FS_I(inode)->i_cluster_size = 0 - tag_pages_for_writeback - f2fs_setattr - truncate_setsize - f2fs_truncate - f2fs_fileattr_set - f2fs_setflags_common - set_compress_context : F2FS_I(inode)->i_cluster_size = 4 : set_inode_flag(inode, FI_COMPRESSED_FILE) - f2fs_compressed_file : return true - f2fs_all_cluster_page_ready : "pgidx % cc->cluster_size" trigger dividing 0 issueLet's change as below to fix this issue:- introduce a new atomic type variable .writeback in structure f2fs_inode_infoto track the number of threads which calling f2fs_write_cache_pages().- use .i_sem lock to protect .writeback update.- check .writeback before update compression context in f2fs_setflags_common()to avoid race w/ ->writepages.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_createWhen sync() and link() are called concurrently, both threads mayenter hfs_bnode_find() without finding the node in the hash tableand proceed to create it.Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it.Thread B also tries to create the same bnode, notices it has alreadybeen inserted, drops its own instance, and uses the hashed one withoutgetting the node.``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; }```However, hfs_bnode_find() requires each call to take a reference.Here both threads end up setting refcnt=1. When they later put the node,this triggers:BUG_ON(!atomic_read(&node->refcnt))In this scenario, Thread B in fact finds the node in the hash tablerather than creating a new one, and thus must take a reference.Fix this by calling hfs_bnode_get() when reusing a bnode newly created byanother thread to ensure the refcount is updated correctly.A similar bug was fixed in HFS long ago in commita9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")but the same issue remained in HFS+ until now.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't log conflicting inode if it's a dir moved in the current transactionWe can't log a conflicting inode if it's a directory and it was movedfrom one parent directory to another parent directory in the currenttransaction, as this can result an attempt to have a directory withtwo hard links during log replay, one for the old parent directory andanother for the new parent directory.The following scenario triggers that issue:1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory;2) We move "dir1" to some other directory;3) We create a file with the name "dir1" in directory inode A;4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1";5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name();6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory);7) We have a power failure;8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1".As a result after log replay finishes when we trigger writeback of thesubvolume tree's extent buffers, the tree check will detect that we havea directory a hard link count of 2 and we get a mount failure.The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [ 3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [ 3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [ 3845.737816] location key (257 1 0) type 2 [---truncated---
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: fix use-after-free on probe deferralThe driver is dropping the references taken to the larb devices duringprobe after successful lookup as well as on errors. This canpotentially lead to a use-after-free in case a larb device has not yetbeen bound to its driver so that the iommu driver probe defers.Fix this by keeping the references as expected while the iommu driver isbound.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()The ethtool tsconfig Netlink path can trigger a null pointerdereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower()results in generic_hwtstamp_ioctl_lower() being called withkernel_cfg->ifr as NULL.The generic_hwtstamp_ioctl_lower() function does not expecta NULL ifr and dereferences it, leading to a system crash.Fix this by adding a NULL check for kernel_cfg->ifr ingeneric_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: libsodium before ad3004e, in atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsodium23 > 0-0 (version in image is 1.0.18-150000.4.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd/selftest: Check for overflow in IOMMU_TEST_OP_ADD_RESERVEDsyzkaller found it could overflow math in the test infrastructure andcause a WARN_ON by corrupting the reserved interval tree. This onlyeffects test kernels with CONFIG_IOMMUFD_TEST.Validate the user input length in the test ioctl.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).
-
Description: In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.
Packages affected:
- sle-module-desktop-applications-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).
-
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).
-
Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.1).
-
Description: A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- glib2-tools > 0-0 (version in image is 2.78.6-150600.4.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix isochronous Ring Underrun/Overrun event handlingThe TRB pointer of these events points at enqueue at the time of erroroccurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time weare handling the event, a new TD may be queued at this ring position.I can trigger this race by rising interrupt moderation to increase IRQhandling delay. Similar delay may occur naturally due to system load.If this ever happens after a Missed Service Error, missed TDs will beskipped and the new TD processed as if it matched the event. It couldbe given back prematurely, risking data loss or buffer UAF by the xHC.Don't complete TDs on xrun events and don't warn if queued TDs don'tmatch the event's TRB pointer, which can be NULL or a link/no-op TRB.Don't warn if there are no queued TDs at all.Now that it's safe, also handle xrun events if the skip flag is clear.This ensures completion of any TD stuck in 'error mid TD' state rightbefore the xrun event, which could happen if a driver submits a finitenumber of URBs to a buggy HC and then an error occurs on the last TD.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RTOn PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, thecurrent task can be preempted. Another task running on the same CPUmay then execute rt6_make_pcpu_route() and successfully install apcpu_rt entry. When the first task resumes execution, its cmpxchg()in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longerNULL, triggering the BUG_ON(prev). It's easy to reproduce it by addingmdelay() after rt6_get_pcpu_route().Using preempt_disable/enable is not appropriate here becauseip6_rt_pcpu_alloc() may sleep.Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT:free our allocation and return the existing pcpu_rt installed byanother task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RTkernels where such races should not occur.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/zctx: check chained notif contextsSend zc only links ubuf_info for requests coming from the same context.There are some ambiguous syz reports, so let's check the assumption onnotification completion.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.1).
-
Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.1).
-
Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- iproute2 > 0-0 (version in image is 6.4-150600.7.9.1).
-
Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be exploited.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error pathsWhen processing mount options, efivarfs allocates efivarfs_fs_info (sfi)early in fs_context initialization. However, sfi is associated with thesuperblock and typically freed when the superblock is destroyed. If thefs_context is released (final put) before fill_super is called-such ason error paths or during reconfiguration-the sfi structure would leak,as ownership never transfers to the superblock.Implement the .free callback in efivarfs_context_ops to ensure anyallocated sfi is properly freed if the fs_context is torn down beforefill_super, preventing this memory leak.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gettext-runtime > 0-0 (version in image is 0.21.1-150600.3.3.2).
-
Description: REXML is an XML toolkit for Ruby. The REXML gems from 3.3.3 to 3.4.1 has a DoS vulnerability when parsing XML containing multiple XML declarations. If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities. The REXML gem 3.4.2 or later include the patches to fix these vulnerabilities.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150700.24.3.1).
-
Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- binutils > 0-0 (version in image is 2.45-150100.7.57.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).
-
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:
- sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.25.1).