-
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: The email module, specifically the "BytesGenerator" class, didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. This is only applicable if using "LiteralHeader" writing headers that don't respect email folding rules, the new behavior will reject the incorrectly folded headers in "BytesGenerator".
Packages affected:
- sles-release == 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: 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: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix error recovery in macvlan_common_newlink()valis provided a nice repro to crash the kernel:ip link add p1 type veth peer p2ip link set address 00:00:00:00:00:20 dev p1ip link set up dev p1ip link set up dev p2ip link add mv0 link p2 type macvlan mode sourceip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20ping -c1 -I p1 1.2.3.4He also gave a very detailed analysis:The issue is triggered when a new macvlan link is created withMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (orMACVLAN_MACADDR_SET) parameter, lower device already has a macvlanport and register_netdevice() called from macvlan_common_newlink()fails (e.g. because of the invalid link name).In this case macvlan_hash_add_source is called frommacvlan_change_sources() / macvlan_common_newlink():This adds a reference to vlan to the port's vlan_source_hash usingmacvlan_source_entry.vlan is a pointer to the priv data of the link that is being created.When register_netdevice() fails, the error is returned frommacvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; }and free_netdev() is called, causing a kvfree() on the structnet_device that is still referenced in the source entry attached tothe lower device's macvlan port.Now all packets sent on the macvlan port with a matching source macaddress will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources()regardless of @create value whenever "goto destroy_macvlan_port;"path is taken.Many thanks to valis for following up on this issue.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix out-of-bounds access in sysfs attribute read/writeSome f2fs sysfs attributes suffer from out-of-bounds memory access andincorrect handling of integer values whose size is not 4 bytes.For example:vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_outvm:~# cat /sys/fs/f2fs/vde/carve_out65537vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_thresholdvm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold1carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bitinteger. However, the sysfs interface allows setting it to a valuelarger than 255, resulting in an out-of-range update.atgc_age_threshold maps to {struct atgc_management}->age_threshold,which is a 64-bit integer, but its sysfs interface cannot correctly setvalues larger than UINT_MAX.The root causes are:1. __sbi_store() treats all default values as unsigned int, whichprevents updating integers larger than 4 bytes and causes out-of-boundswrites for integers smaller than 4 bytes.2. f2fs_sbi_show() also assumes all default values are unsigned int,leading to out-of-bounds reads and incorrect access to integers largerthan 4 bytes.This patch introduces {struct f2fs_attr}->size to record the actual sizeof the integer associated with each sysfs attribute. With thisinformation, sysfs read and write operations can correctly access andupdate values according to their real data size, avoiding memorycorruption and truncation.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/umad: Reject negative data_len in ib_umad_writeib_umad_write computes data_len from user-controlled count and theMAD header sizes. With a mismatched user MAD header size and RMPPheader length, data_len can become negative and reach ib_create_send_mad().This can make the padding calculation exceed the segment size and triggeran out-of-bounds memset in alloc_send_rmpp_list().Add an explicit check to reject negative data_len before creating thesend buffer.KASAN splat:[ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0[ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102[ 211.365867] ib_create_send_mad+0xa01/0x11b0[ 211.365887] ib_umad_write+0x853/0x1c80
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- xen-libs > 0-0 (version in image is 4.20.2_06-150700.3.25.1).
-
Description: A flaw was found in systemd. The systemd-machined service contains an Improper Access Control vulnerability due to insufficient validation of the class parameter in the RegisterMachine D-Bus (Desktop Bus) method. A local unprivileged user can exploit this by attempting to register a machine with a specific class value, which may leave behind a usable, attacker-controlled machine object. This allows the attacker to invoke methods on the privileged object, leading to the execution of arbitrary commands with root privileges on the host system.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsystemd0 > 0-0 (version in image is 254.27-150600.4.55.1).
-
Description: When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_6m1_0 < 3.6.15-150300.10.106.1 (version in image is 3.6.15-150300.10.103.1).
-
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
- sle-module-containers-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd-ctr > 0-0 (version in image is 1.7.29-150000.128.1).
-
Description: 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).
- libpython3_6m1_0 < 3.6.15-150300.10.106.1 (version in image is 3.6.15-150300.10.103.1).
-
Description: libcurl can in some circumstances reuse the wrong connection when asked to doan Negotiate-authenticated HTTP or HTTPS request.libcurl features a pool of recent connections so that subsequent requests canreuse an existing connection to avoid overhead.When reusing a connection a range of criterion must first be met. Due to alogical error in the code, a request that was issued by an application couldwrongfully reuse an existing connection to the same server that wasauthenticated using different credentials. One underlying reason being thatNegotiate sometimes authenticates *connections* and not *requests*, contraryto how HTTP is designed to work.An application that allows Negotiate authentication to a server (that respondswanting Negotiate) with `user1:password1` and then does another operation tothe same server also using Negotiate but with `user2:password2` (while theprevious connection is still alive) - the second request wrongly reused thesame connection and since it then sees that the Negotiate negotiation isalready made, it just sends the request over that connection thinking it usesthe user2 credentials when it is in fact still using the connectionauthenticated for user1...The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.Applications can disable libcurl's reuse of connections and thus mitigate thisproblem, by using one of the following libcurl options to alter howconnections are or are not reused: `CURLOPT_FRESH_CONNECT`,`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using thecurl_multi API).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl < 8.14.1-150700.7.14.1 (version in image is 8.14.1-150700.7.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error pathsThe problem occurs when a signed request fails smb2 signature verificationcheck. In __process_request(), if check_sign_req() returns an error,set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resettingnext_smb2_rcv_hdr_off to zero, the pointer to the next command in the chainis lost. Consequently, is_chained_smb2_message() continues to point tothe same request header instead of advancing. If the header's NextCommandfield is non-zero, the function returns true, causing __handle_ksmbd_work()to repeatedly process the same failed request in an infinite loop.This results in the kernel log being flooded with "bad smb2 signature"messages and high CPU usage.This patch fixes the issue by changing the return value fromSERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures thatthe processing loop terminates immediately rather than attempting tocontinue from an invalidated offset.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libnghttp2-14 > 0-0 (version in image is 1.64.0-150700.1.5).
-
Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.3, the `pyasn1` library is vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding ASN.1 data with deeply nested structures. An attacker can supply a crafted payload containing thousands of nested `SEQUENCE` (`0x30`) or `SET` (`0x31`) tags with "Indefinite Length" (`0x80`) markers. This forces the decoder to recursively call itself until the Python interpreter crashes with a `RecursionError` or consumes all available memory (OOM), crashing the host application. This is a distinct vulnerability from CVE-2026-23490 (which addressed integer overflows in OID decoding). The fix for CVE-2026-23490 (`MAX_OID_ARC_CONTINUATION_OCTETS`) does not mitigate this recursion issue. Version 0.6.3 fixes this specific issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-pyasn1 > 0-0 (version in image is 0.4.2-150000.3.13.1).
-
Description: PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 ?4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC. This vulnerability is fixed in 2.12.0.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- python3-PyJWT > 0-0 (version in image is 2.4.0-150200.3.8.1).
-
Description: libexpat before 2.7.5 allows a NULL pointer dereference with empty external parameter entity content.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.1).
-
Description: libexpat before 2.7.5 allows an infinite loop while parsing DTD content.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.1).
-
Description: When an Expat parser with a registered ElementDeclHandler parses an inlinedocument type definition containing a deeply nested content model a C stackoverflow occurs.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: aloop: Fix racy access at PCM triggerThe PCM trigger callback of aloop driver tries to check the PCM stateand stop the stream of the tied substream in the corresponding cable.Since both check and stop operations are performed outside the cablelock, this may result in UAF when a program attempts to triggerfrequently while opening/closing the tied stream, as spotted byfuzzers.For addressing the UAF, this patch changes two things:- It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses.- In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- xen-libs > 0-0 (version in image is 4.20.2_06-150700.3.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sva: invalidate stale IOTLB entries for kernel address spaceIntroduce a new IOMMU interface to flush IOTLB paging cache entries forthe CPU kernel address space. This interface is invoked from the x86architecture code that manages combined user and kernel page tables,specifically before any kernel page table page is freed and reused.This addresses the main issue with vfree() which is a common occurrenceand can be triggered by unprivileged users. While this resolves theprimary problem, it doesn't address some extremely rare case related tomemory unplug of memory that was present as reserved memory at boot, whichcannot be triggered by unprivileged users. The discussion can be found atthe link below.Enable SVA on x86 architecture since the IOMMU can now receivenotification to flush the paging cache before freeing the CPU kernel pagetable pages.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()in an interesting way [1]Crash happens in list_del_init()/INIT_LIST_HEAD() while writinglist->prev, while the prior write on list->next went well.static inline void INIT_LIST_HEAD(struct list_head *list){ WRITE_ONCE(list->next, list); // This went well WRITE_ONCE(list->prev, list); // Crash, @list has been freed.}Issue here is that rt6_uncached_list_del() did not attempt to lockul->lock, as list_empty(&rt->dst.rt_uncached) returnedtrue because the WRITE_ONCE(list->next, list) happened on the other CPU.We might use list_del_init_careful() and list_empty_careful(),or make sure rt6_uncached_list_del() always grabs the spinlockwhenever rt->dst.rt_uncached_list has been set.A similar fix is neeed for IPv4.[1] BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline] BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline] BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: netns cleanup_netCall Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 INIT_LIST_HEAD include/linux/list.h:46 [inline] list_del_init include/linux/list.h:296 [inline] rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853 addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] netif_close_many+0x29c/0x410 net/core/dev.c:1785 unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248 cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 803: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4953 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270 dst_alloc+0x105/0x170 net/core/dst.c:89 ip6_dst_alloc net/ipv6/route.c:342 [inline] icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333 mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recvmsg() unconditional requeueIf rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call atthe front of the recvmsg queue already has its mutex locked, it requeuesthe call - whether or not the call is already queued. The call may be onthe queue because MSG_PEEK was also passed and so the call was not dequeuedor because the I/O thread requeued it.The unconditional requeue may then corrupt the recvmsg queue, leading tothings like UAFs or refcount underruns.Fix this by only requeuing the call if it isn't already on the queue - andmoving it to the front if it is already queued. If we don't queue it, wehave to put the ref we obtained by dequeuing it.Also, MSG_PEEK doesn't dequeue the call so shouldn't callrxrpc_notify_socket() for the call if we didn't use up all the data on thequeue, so fix that also.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Enforce that teql can only be used as root qdiscDesign intent of teql is that it is only supposed to be used as root qdisc.We need to check for that constraint.Although not important, I will describe the scenario that unearthed thisissue for the curious.GangMin Kim managed to concot a scenario as follows:ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s ── class 1:2 (weight=1, lmax=1514) teqlGangMin sends a packet which is enqueued to 1:1 (netem).Any invocation of dequeue by QFQ from this class will not return a packetuntil after 6.4s. In the meantime, a second packet is sent and it lands on1:2. teql's enqueue will return success and this will activate class 1:2.Main issue is that teql only updates the parent visible qlen (sch->q.qlen)at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql'speek always returns NULL), dequeue will never be called and thus the qlenwill remain as 0. With that in mind, when GangMin updates 1:2's lmax value,the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc'sqlen was not incremented, qfq fails to deactivate the class, but stillfrees its pointers from the aggregate. So when the first packet isrescheduled after 6.4 seconds (netem's delay), a dangling pointer isaccessed causing GangMin's causing a UAF.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_u32: use skb_header_pointer_careful()skb_header_pointer() does not fully validate negative @offset values.Use skb_header_pointer_careful() instead.GangMin Kim provided a report and a repro fooling u32_classify():BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0net/sched/cls_u32.c:221
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/freeExynos Virtual Display driver performs memory alloc/free operationswithout lock protection, which easily causes concurrency problem.For example, use-after-free can occur in race scenario like this:``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ...```To prevent these vulns, at least in vidi_context, member variables relatedto memory alloc/free should be protected with ctx->lock.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix use-after-free in nf_tables_addchain()nf_tables_addchain() publishes the chain to table->chains vialist_add_tail_rcu() (in nft_chain_add()) before registering hooks.If nf_tables_register_hook() then fails, the error path callsnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()with no RCU grace period in between.This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain.Add synchronize_rcu() between nft_chain_del() and the chain destroyso that all RCU readers -- both dump threads and in-flight packetevaluation -- have finished before the chain is freed.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix refcount bug and potential UAF in perf_mmapSyzkaller reported a refcount_t: addition on 0; use-after-free warningin perf_mmap.The issue is caused by a race condition between a failing mmap() setupand a concurrent mmap() on a dependent event (e.g., using outputredirection).In perf_mmap(), the ring_buffer (rb) is allocated and assigned toevent->rb with the mmap_mutex held. The mutex is then released toperform map_range().If map_range() fails, perf_mmap_close() is called to clean up.However, since the mutex was dropped, another thread attaching tothis event (via inherited events or output redirection) can acquirethe mutex, observe the valid event->rb pointer, and attempt toincrement its reference count. If the cleanup path has alreadydropped the reference count to zero, this results in ause-after-free or refcount saturation warning.Fix this by extending the scope of mmap_mutex to cover themap_range() call. This ensures that the ring buffer initializationand mapping (or cleanup on failure) happens atomically effectively,preventing other threads from accessing a half-initialized ordying ring buffer.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix unprivileged local user can do privileged policy managementAn unprivileged local user can load, replace, and remove profiles byopening the apparmorfs interfaces, via a confused deputy attack, bypassing the opened fd to a privileged process, and getting theprivileged process to write to the interface.This does require a privileged target that can be manipulated to dothe write for the unprivileged process, but once such access isachieved full policy management is possible and all the possibleimplications that implies: removing confinement, DoS of system ortarget applications by denying all execution, by-passing theunprivileged user namespace restriction, to exploiting kernel bugs fora local privilege escalation.The policy management interface can not have its permissions simplychanged from 0666 to 0600 because non-root processes need to be ableto load policy to different policy namespaces.Instead ensure the task writing the interface has privileges thatare a subset of the task that opened the interface. This is alreadydone via policy for confined processes, but unconfined can delegateaccess to the opened fd, by-passing the usual policy check.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: The webbrowser.open() API would accept leading dashes in the URL which could be handled as command line options for certain web browsers. New behavior rejects leading dashes. Users are recommended to sanitize URLs prior to passing to webbrowser.open().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_6m1_0 < 3.6.15-150300.10.106.1 (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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_6m1_0 < 3.6.15-150300.10.106.1 (version in image is 3.6.15-150300.10.103.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: provide locking for v4_end_graceWriting to v4_end_grace can race with server shutdown and result inmemory being accessed after it was freed - reclaim_str_hashtbl inparticularly.We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that isheld while client_tracking_op->init() is called and that can wait foran upcall to nfsdcltrack which can write to v4_end_grace, resulting in adeadlock.nfsd4_end_grace() is also called by the landromat work queue and thisdoesn't require locking as server shutdown will stop the work and waitfor it before freeing anything that nfsd4_end_grace() might access.However, we must be sure that writing to v4_end_grace doesn't restartthe work item after shutdown has already waited for it. For this weadd a new flag protected with nn->client_lock. It is set only while itis safe to make client tracking calls, and v4_end_grace only scheduleswork while the flag is set with the spinlock held.So this patch adds a nfsd_net field "client_tracking_active" which isset as described. Another field "grace_end_forced", is set whenv4_end_grace is written. After this is set, and providingclient_tracking_active is set, the laundromat is scheduled.This "grace_end_forced" field bypasses other checks for whether thegrace period has finished.This resolves a race which can result in use-after-free.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()Blamed commit did not take care of VLAN encapsulationsas spotted by syzbot [1].Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Coalesce only linear skbvsock/virtio common tries to coalesce buffers in rx queue: if a linear skb(with a spare tail room) is followed by a small skb (length limited byGOOD_COPY_LEN = 128), an attempt is made to join them.Since the introduction of MSG_ZEROCOPY support, assumption that a small skbwill always be linear is incorrect. In the zerocopy case, data is lost andthe linear skb is appended with uninitialized kernel memory.Of all 3 supported virtio-based transports, only loopback-transport isaffected. G2H virtio-transport rx queue operates on explicitly linear skbs;see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2Gvhost-transport may allocate non-linear skbs, but only for sizes that arenot considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER invirtio_vsock_alloc_skb().Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) > 0guarantees last_skb is linear.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate theprivileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'root_squash' or 'all_squash' attributes that would normally be expected to apply to that client.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libnfsidmap1 > 0-0 (version in image is 1.0-150600.28.12.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_6m1_0 < 3.6.15-150300.10.106.1 (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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libpython3_6m1_0 < 3.6.15-150300.10.106.1 (version in image is 3.6.15-150300.10.103.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config < 0.9.8-150600.11.9.1 (version in image is 0.9.8-150600.11.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: cap TX credit to local buffer sizeThe virtio transports derives its TX credit directly from peer_buf_alloc,which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.On the host side this means that the amount of data we are willing toqueue for a connection is scaled by a guest-chosen buffer size, ratherthan the host's own vsock configuration. A malicious guest can advertisea large buffer and read slowly, causing the host to allocate acorrespondingly large amount of sk_buff memory.The same thing would happen in the guest with a malicious host, sincevirtio transports share the same code base.Introduce a small helper, virtio_transport_tx_buf_size(), thatreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consumepeer_buf_alloc.This ensures the effective TX window is bounded by both the peer'sadvertised buffer and our own buf_alloc (already clamped tobuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peercannot force the other to queue more data than allowed by its ownvsock settings.On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with32 guest vsock connections advertising 2 GiB each and reading slowlydrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system onlyrecovered after killing the QEMU process. That said, if QEMU memory islimited with cgroups, the maximum memory used will be limited.With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiBOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guestremains responsive.Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.This change is limited to virtio_transport_common.c and thus affectsvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the"remote window intersected with local policy" behaviour that VMCI andHyper-V already effectively have.[Stefano: small adjustments after changing the previous patch][Stefano: tweak the commit message]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix UAF in xchk_btree_check_block_ownerWe cannot dereference bs->cur when trying to determine if bs->curaliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.Fix this by sampling before type before any freeing could happen.The correct temporal ordering was broken when we removed xfs_btnum_t.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add xmit recursion limit to tunnel xmit functionsTunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their ownrecursion limit. When a bond device in broadcast mode has GRE tapinterfaces as slaves, and those GRE tunnels route back through thebond, multicast/broadcast traffic triggers infinite recursion betweenbond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causingkernel stack overflow.The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is notsufficient because tunnel recursion involves route lookups and full IPoutput, consuming much more stack per level. Use a lower limit of 4(IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.Add recursion detection using dev_xmit_recursion helpers directly iniptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnelpaths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).Move dev_xmit_recursion helpers from net/core/dev.h to public headerinclude/linux/netdevice.h so they can be used by tunnel code. BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mld_ifc_work Call Trace: __build_flow_key.constprop.0 (net/ipv4/route.c:515) ip_rt_update_pmtu (net/ipv4/route.c:1073) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) mld_sendpack mld_ifc_work process_one_work worker_thread
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libavahi-client3 > 0-0 (version in image is 0.8-150600.15.12.1).
-
Description: In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 < 2.7.1-150700.3.9.2 (version in image is 2.7.1-150700.3.6.1).
-
Description: Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: The fix for CVE-2026-0672, which rejected control characters in http.cookies.Morsel, was incomplete. The Morsel.update(), |= operator, and unpickling paths were not patched, allowing control characters to bypass input validation. Additionally, BaseCookie.js_output() lacked the output validation applied to BaseCookie.output().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_gate: snapshot parameters with RCU on replaceThe gate action can be replaced while the hrtimer callback or dump path iswalking the schedule list.Convert the parameters to an RCU-protected snapshot and swap updates undertcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omitsthe entry list, preserve the existing schedule so the effective state isunchanged.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: unconditionally bump set->nelems before insertionIn case that the set is full, a new element gets published then removedwithout waiting for the RCU grace period, while RCU reader can bewalking over it already.To address this issue, add the element transaction even if set is full,but toggle the set_full flag to report -ENFILE so the abort path safelyunwinds the set to its previous state.As for element updates, decrement set->nelems to restore it.A simpler fix is to call synchronize_rcu() in the error path.However, with a large batch adding elements to already maxed-out set,this could cause noticeable slowdown of such batches.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gve: Fix stats report corruption on queue count changeThe driver and the NIC share a region in memory for stats reporting.The NIC calculates its offset into this region based on the total sizeof the stats region and the size of the NIC's stats.When the number of queues is changed, the driver's stats region isresized. If the queue count is increased, the NIC can write pastthe end of the allocated stats region, causing memory corruption.If the queue count is decreased, there is a gap between the driverand NIC stats, leading to incorrect stats reporting.This change fixes the issue by allocating stats region with maximumsize, and the offset calculation for NIC stats is changed to matchwith the calculation of the NIC.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix use-after-free in inet6_addr_del().syzbot reported use-after-free of inet6_ifaddr ininet6_addr_del(). [0]The cited commit accidentally moved ipv6_del_addr() formngtmpaddr before reading its ifp->flags for temporaryaddresses in inet6_addr_del().Let's move ipv6_del_addr() down to fix the UAF.[0]:BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f164cf8f749Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 Allocated by task 9593: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 6099: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free_freelist_hook mm/slub.c:2569 [inline] slab_free_bulk mm/slub.c:6696 [inline] kmem_cache_free_bulk mm/slub.c:7383 [inline] kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362 kfree_bulk include/linux/slab.h:830 [inline] kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523 kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline] kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801 process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257 process_scheduled_works kernel/workqu---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: validate DFA start states are in bounds in unpack_pdbStart states are read from untrusted data and used as indexes into theDFA state tables. The aa_dfa_next() function call in unpack_pdb() willaccess dfa->tables[YYTD_ID_BASE][start], and if the start state exceedsthe number of states in the DFA, this results in an out-of-bound read.================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...Reject policies with out-of-bounds start states during unpackingto prevent the issue.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: cloud-init through 25.1.2 includes the systemd socket unit cloud-init-hotplugd.socket with default SocketMode that grants 0666 permissions, making it world-writable. This is used for the "/run/cloud-init/hook-hotplug-cmd" FIFO. An unprivileged user could trigger hotplug-hook commands.
Packages affected:
- sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
- cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).
-
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- gpg2 > 0-0 (version in image is 2.4.4-150600.3.15.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix double-free in nr_route_frame()In nr_route_frame(), old_skb is immediately freed without checking ifnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,the caller function will free old_skb again, causing a double-free bug.Therefore, to prevent this, we need to modify it to check whethernr_neigh->ax25 is NULL before freeing old_skb.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmitteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmitthrough slave devices, but does not update skb->dev to the slave devicebeforehand.When a gretap tunnel is a TEQL slave, the transmit path reachesiptunnel_xmit() which saves dev = skb->dev (still pointing to teql0master) and later calls iptunnel_xmit_stats(dev, pkt_len). Thisfunction does: get_cpu_ptr(dev->tstats)Since teql_master_setup() does not set dev->pcpu_stat_type toNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstatsfor teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computesNULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)Fix this by setting skb->dev = slave before callingnetdev_start_xmit(), so that tunnel xmit functions see the correctslave device with properly allocated tstats.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: libexpat before 2.7.5 allows a NULL pointer dereference in the function setContext on retry after an earlier ouf-of-memory condition.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.1).
-
Description: Calling NSS-backed functions that support caching via nscd may call the nscd client side code and in the GNU C Library version 2.36 under high load on x86_64 systems, the client may call memcmp on inputs that are concurrently modified by other processes or threads and crash.The nscd client in the GNU C Library uses the memcmp function with inputs that may be concurrently modified by another thread, potentially resulting in spurious cache misses, which in itself is not a security issue. However in the GNU C Library version 2.36 an optimized implementation of memcmp was introduced for x86_64 which could crash when invoked with such undefined behaviour, turning this into a potential crash of the nscd client and the application that uses it. This implementation was backported to the 2.35 branch, making the nscd client in that branch vulnerable as well. Subsequently, the fix for this issue was backported to all vulnerable branches in the GNU C Library repository.It is advised that distributions that may have cherry-picked the memcpy SSE2 optimization in their copy of the GNU C Library, also apply the fix to avoid the potential crash in the nscd client.
Packages affected:
- 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.40.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()In iscsit_dec_session_usage_count(), the function calls complete() whileholding the sess->session_usage_lock. Similar to the connection usage countlogic, the waiter signaled by complete() (e.g., in the session releasepath) may wake up and free the iscsit_session structure immediately.This creates a race condition where the current thread may attempt toexecute spin_unlock_bh() on a session structure that has already beendeallocated, resulting in a KASAN slab-use-after-free.To resolve this, release the session_usage_lock before calling complete()to ensure all dereferences of the sess pointer are finished before thewaiter is allowed to proceed with deallocation.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()and/or mptcp_pm_nl_is_backup()Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()which is not RCU ready.list_splice_init_rcu() can not be called here while holding pernet->lockspinlock.Many thanks to Eulgyu Kim for providing a repro and testing our patches.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Unknown.
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:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fs/xattr: missing fdput() in fremovexattr error pathIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire afile reference but returns early without calling fdput() whenstrncpy_from_user() fails on the name argument. In multi-threaded processeswhere fdget() takes the slow path, this permanently leaks onefile reference per call, pinning the struct file and associated kernelobjects in memory. An unprivileged local user can exploit this to causekernel memory exhaustion. The issue was inadvertently fixed by commita71874379ec8 ("xattr: switch to CLASS(fd)").
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Forget ranges when refining tnum after JSETSyzbot reported a kernel warning due to a range invariant violation onthe following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps.That path is unreachable at runtime: after insn 1, we know r0 != 0, butwith the sign extension on the jset, we would only fallthrough insn 2if r0 == 0. Unfortunately, is_branch_taken() isn't currently able tofigure this out, so the verifier walks all branches. The verifier thenrefines the register bounds using the second condition and we endup with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0)Improving the range refinement for JSET to cover all cases is tricky. Wealso don't expect many users to rely on JSET given LLVM doesn't generatethose instructions. So instead of improving the range refinement forJSETs, Eduard suggested we forget the ranges whenever we're narrowingtnums after a JSET. This patch implements that approach.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslotReject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that wasinitially created with a guest_memfd binding, as KVM doesn't supporttoggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enablingKVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.Failure to reject the new memslot results in a use-after-free due to KVMnot unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLYchange is easy enough, and can/will be done as a hardening measure (inanticipation of KVM supporting dirty logging on guest_memfd at some point),but fixing the use-after-free would only address the immediate symptom. ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745 CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5c0 kasan_report+0xb4/0xe0 kvm_gmem_release+0x362/0x400 [kvm] __fput+0x2fa/0x9d0 task_work_run+0x12c/0x200 do_exit+0x6ae/0x2100 do_group_exit+0xa8/0x230 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0x737/0x740 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 Allocated by task 745 on cpu 6 at 9.746971s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_kmalloc+0x77/0x90 kvm_set_memory_region.part.0+0x652/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 745 on cpu 6 at 9.747467s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x3b/0x60 kfree+0xf5/0x440 kvm_set_memslot+0x3c2/0x1160 [kvm] kvm_set_memory_region.part.0+0x86a/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: disable recursive forward error correctionThere are two problems with the recursive correction:1. It may cause denial-of-service. In fec_read_bufs, there is a loop thathas 253 iterations. For each iteration, we may call verity_hash_for_blockrecursively. There is a limit of 4 nested recursions - that means thatthere may be at most 253^4 (4 billion) iterations. Red Hat QE teamactually created an image that pushes dm-verity to this limit - and thisimage just makes the udev-worker process get stuck in the 'D' state.2. It doesn't work. In fec_read_bufs we store data into the variable"fio->bufs", but fio bufs is shared between recursive invocations, if"verity_hash_for_block" invoked correction recursively, it wouldoverwrite partially filled fio->bufs.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:counter: interrupt-cnt: Drop IRQF_NO_THREAD flagAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, asCONFIG_PROVE_RAW_LOCK_NESTING warns:=============================[ BUG: Invalid wait context ]6.18.0-rc1+git... #1-----------------------------some-user-space-process/1251 is trying to lock:(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]other info that might help us debug this:context-{2:2}no locks held by some-user-space-process/....stack backtrace:CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPTCall trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq... and Sebastian correctly points out. Remove IRQF_NO_THREAD as analternative to switching to raw_spinlock_t, because the latter would limitall potential nested locks to raw_spinlock_t only.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always detect conflicting inodes when logging inode refsAfter rename exchanging (either with the rename exchange operation orregular renames in multiple non-atomic steps) two inodes and at leastone of them is a directory, we can end up with a log tree that containsonly of the inodes and after a power failure that can result in an attemptto delete the other inode when it should not because it was not deletedbefore the power failure. In some case that delete attempt fails whenthe target inode is a directory that contains a subvolume inside it, sincethe log replay code is not prepared to deal with directory entries thatpoint to root items (only inode items).1) We have directories "dir1" (inode A) and "dir2" (inode B) under the same parent directory;2) We have a file (inode C) under directory "dir1" (inode A);3) We have a subvolume inside directory "dir2" (inode B);4) All these inodes were persisted in a past transaction and we are currently at transaction N;5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N;6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B), so after the exchange "dir1" is inode B and "dir2" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N;7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()).8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction);9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87.---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix NULL dereference on root when tracing inode evictionWhen evicting an inode the first thing we do is to setup tracing for it,which implies fetching the root's id. But in btrfs_evict_inode() theroot might be NULL, as implied in the next check that we do inbtrfs_evict_inode().Hence, we either should set the ->root_objectid to 0 in case the root isNULL, or we move tracing setup after checking that the root is notNULL. Setting the rootid to 0 at least gives us the possibility to tracethis call even in the case when the root is NULL, so that's the solutiontaken here.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't WARN for connections on invalid channelsIt's not clear (to me) how exactly syzbot managed to hit this,but it seems conceivable that e.g. regulatory changed and hasdisabled a channel between scanning (channel is checked to beusable by cfg80211_get_ies_channel_number) and connecting onthe channel later.With one scenario that isn't covered elsewhere described above,the warning isn't good, replace it with a (more informative)error message.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix crash when adding interface under a lagCommit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag")fixed a similar issue in the lan966x driver caused by a NULL pointer dereference.The ocelot_set_aggr_pgids() function in the ocelot driver has similar logicand is susceptible to the same crash.This issue specifically affects the ocelot_vsc7514.c frontend, which leavesunused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected asit uses the DSA framework which registers all ports.Fix this by checking if the port pointer is valid before accessing it.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: check that server is running in unlock_filesystemIf we are trying to unlock the filesystem via an administrativeinterface and nfsd isn't running, it crashes the server. Thishappens currently because nfsd4_revoke_states() access statestructures (eg., conf_id_hashtbl) that has been freed as a partof the server shutdown.[ 59.465072] Call trace:[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd][ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd][ 59.466780] vfs_write+0x1f0/0x938[ 59.467088] ksys_write+0xfc/0x1f8[ 59.467395] __arm64_sys_write+0x74/0xb8[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8[ 59.468177] do_el0_svc+0x154/0x1d8[ 59.468489] el0_svc+0x40/0xe0[ 59.468767] el0t_64_sync_handler+0xa0/0xe8[ 59.469138] el0t_64_sync+0x1ac/0x1b0Ensure this can't happen by taking the nfsd_mutex and checking thatthe server is still up, and then holding the mutex across the call tonfsd4_revoke_states().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovecCommit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")added ttag bounds checking and data_offsetvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validatewhether the command's data structures (cmd->req.sg and cmd->iov) havebeen properly initialized before processing H2C_DATA PDUs.The nvmet_tcp_build_pdu_iovec() function dereferences these pointerswithout NULL checks. This can be triggered by sending H2C_DATA PDUimmediately after the ICREQ/ICRESP handshake, beforesending a CONNECT command or NVMe write command.Attack vectors that trigger NULL pointer dereferences:1. H2C_DATA PDU sent before CONNECT -> both pointers NULL2. H2C_DATA PDU for READ command -> cmd->req.sg allocated, cmd->iov NULL3. H2C_DATA PDU for uninitialized command slot -> both pointers NULLThe fix validates both cmd->req.sg and cmd->iov before callingnvmet_tcp_build_pdu_iovec(). Both checks are required because:- Uninitialized commands: both NULL- READ commands: cmd->req.sg allocated, cmd->iov NULL- WRITE commands: both allocated
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix error handling in the init_task on loadIf the init_task fails during a driver load, we end up without vports andnetdevs, effectively failing the entire process. In that state asubsequent reset will result in a crash as the service task attempts toaccess uninitialized resources. Following trace is from an error in theinit_task where the CREATE_VPORT (op 501) is rejected by the FW:[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)[40958.148190] idpf 0000:83:00.0: HW reset detected[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8...[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf][40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]...[40958.177932] Call Trace:[40958.178491] [40958.179040] process_one_work+0x226/0x6d0[40958.179609] worker_thread+0x19e/0x340[40958.180158] ? __pfx_worker_thread+0x10/0x10[40958.180702] kthread+0x10f/0x250[40958.181238] ? __pfx_kthread+0x10/0x10[40958.181774] ret_from_fork+0x251/0x2b0[40958.182307] ? __pfx_kthread+0x10/0x10[40958.182834] ret_from_fork_asm+0x1a/0x30[40958.183370] Fix the error handling in the init_task to make sure the service andmailbox tasks are disabled if the error happens during load. These arestarted in idpf_vc_core_init(), which spawns the init_task and has no wayof knowing if it failed. If the error happens on reset, followingsuccessful driver load, the tasks can still run, as that will allow thenetdevs to attempt recovery through another reset. Stop the PTP callbackseither way as those will be restarted by the call to idpf_vc_core_init()during a successful reset.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: 3com: 3c59x: fix possible null dereference in vortex_probe1()pdev can be null and free_ring: can be called in 1297 with a nullpdev.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of privmlx5e_priv is an unstable structure that can be memset(0) if profileattaching fails.Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on avalid netdev.On mlx5e_remove: Check validity of priv->profile, before attemptingto cleanup any resources that might be not there.This fixes a kernel oops in mlx5e_remove when switchdev mode fails dueto change profile failure.$ devlink dev eswitch set pci/0000:00:03.0 mode switchdevError: mlx5_core: Failed setting eswitch to offloads.dmesg:workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12$ devlink dev reload pci/0000:00:03.0 ==> oopsBUG: kernel NULL pointer dereference, address: 0000000000000370PGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0Call Trace: mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make calc_target() set t->paused, not just clear itCurrently calc_target() clears t->paused if the request shouldn't bepaused anymore, but doesn't ever set t->paused even though it's able todetermine when the request should be paused. Setting t->paused is leftto __submit_request() which is fine for regular requests but doesn'twork for linger requests -- since __submit_request() doesn't operateon linger requests, there is nowhere for lreq->t.paused to be set.One consequence of this is that watches don't get reestablished onpaused -> unpaused transitions in cases where requests have been pausedlong enough for the (paused) unwatch request to time out and for thesubsequent (re)watch request to enter the paused state. On top of thewatch not getting reestablished, rbd_reregister_watch() gets stuck withrbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_waitIt's waiting for lreq->reg_commit_wait to be completed, but for that tohappen the respective request needs to end up on need_resend_linger listand be kicked when requests are unpaused. There is no chance for thatif the request in question is never marked paused in the first place.The fact that rbd_dev->watch_mutex remains taken out forever thenprevents the image from getting unmapped -- "rbd unmap" would inevitablyhang in D state on an attempt to grab the mutex.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd: Fix memory leak in wbrf_record()The tmp buffer is allocated using kcalloc() but is not freed ifacpi_evaluate_dsm() fails. This causes a memory leak in the error path.Fix this by explicitly freeing the tmp buffer in the error handlingpath of acpi_evaluate_dsm().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:Octeontx2-af: Add proper checks for fwdatafirmware populates MAC address, link modes (supported, advertised)and EEPROM data in shared firmware structure which kernel accessvia MAC block(CGX/RPM).Accessing fwdata, on boards booted with out MAC block leading tokernel panics.Internal error: Oops: 0000000096000005 [#1] SMP[ 10.460721] Modules linked in:[ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT[ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)[ 10.479793] Workqueue: events work_for_cpu_fn[ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 10.491124] pc : rvu_sdp_init+0x18/0x114[ 10.495051] lr : rvu_probe+0xe58/0x1d18
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In esd_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inesd_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in esd_usb_close().Fix the memory leak by anchoring the URB in theesd_usb_read_bulk_callback() to the dev->rx_submitted anchor.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Avoid truncating memory addressesOn 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmemallocations to be backed by addresses physical memory above the 32-bitaddress limit, as found while experimenting with larger VMSPLITconfigurations.This caused the qemu virt model to crash in the GICv3 driver, whichallocates the 'itt' object using GFP_KERNEL. Since all memory belowthe 4GB physical address limit is in ZONE_DMA in this configuration,kmalloc() defaults to higher addresses for ZONE_NORMAL, and theITS driver stores the physical address in a 32-bit 'unsigned long'variable.Change the itt_addr variable to the correct phys_addr_t type instead,along with all other variables in this driver that hold a physicaladdress.The gicv5 driver correctly uses u64 variables, while all other irqchipdrivers don't call virt_to_phys or similar interfaces. It's expected thatother device drivers have similar issues, but fixing this one issufficient for booting a virtio based guest.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()Memory allocated for struct vscsiblk_info in scsiback_probe() is notfreed in scsiback_remove() leading to potential memory leaks on remove,as well as in the scsiback_probe() error paths. Fix that by freeing itin scsiback_remove().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix crash on synthetic stacktrace field usageWhen creating a synthetic event based on an existing synthetic event thathad a stacktrace field and the new synthetic event used that field akernel crash occurred: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/triggerThe above creates a synthetic event that takes a stacktrace when a taskschedules out in a non-running state and passes that stacktrace to thesched_switch event when that task schedules back in. It triggers the"stack" synthetic event that has a stacktrace as its field (called "stack"). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/triggerThe above makes another synthetic event called "syscall_stack" thatattaches the first synthetic event (stack) to the sys_exit trace event andrecords the stacktrace from the stack event with the id of the system callthat is exiting.When enabling this event (or using it in a historgram): ~# echo 1 > events/synthetic/syscall_stack/enableProduces a kernel crash! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reason is that the stacktrace field is not labeled as such, and istreated as a normal field and not as a dynamic event that it is.In trace_event_raw_event_synth() the event is field is still treated as adynamic array, but the retrieval of the data is considered a normal field,and the reference is just the meta data:// Meta data is retrieved instead of a dynamic array---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: core: fix device reference leak on report presentSlimbus devices can be allocated dynamically upon reception ofreport-present messages.Make sure to drop the reference taken when looking up already registereddevices.Note that this requires taking an extra reference in case the device hasnot yet been registered and has to be allocated.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:gue: Fix skb memleak with inner IP protocol 0.syzbot reported skb memleak below. [0]The repro generated a GUE packet with its inner protocol 0.gue_udp_recv() returns -guehdr->proto_ctype for "resubmit"in ip_protocol_deliver_rcu(), but this only works withnon-zero protocol number.Let's drop such packets.Note that 0 is a valid number (IPv6 Hop-by-Hop Option).I think it is not practical to encap HOPOPT in GUE, so oncesomeone starts to complain, we could pass down a resubmitflag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT[0]BUG: memory leakunreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:migrate: correct lock ordering for hugetlb file foliosSyzbot has found a deadlock (analyzed by Lance Yang):1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquirefolio_lock.migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)!hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock!The migration path is the one taking locks in the wrong order according tothe documentation at the top of mm/rmap.c. So expand the scope of theexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.This is (mostly) how it used to be after commit c0d0381ade79. That wasremoved by 336bf30eb765 for both file & anon hugetlb pages when it shouldonly have been removed for anon hugetlb pages.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: limit BOND_MODE_8023AD to Ethernet devicesBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Fix restoration of SVE contextWhen SME is supported, Restoring SVE signal context can go wrong in afew ways, including placing the task into an invalid state where thekernel may read from out-of-bounds memory (and may potentially take afatal fault) and/or may kill the task with a SIGKILL.(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time.(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length.Fix (1) by setting TIF_SME when setting SVCR.SM. This also requiresensuring that the task's sme_state has been allocated, but as this couldcontain live ZA state, it should not be zeroed. Fix (2) by clearingSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME,and fp_type earlier, immediately after the allocation ofsve_state/sme_state, before the restore of the actual register state.This makes it easier to ensure that these are always modifiedconsistently, even if a fault is taken while reading the register datafrom the signal context. I do not expect any software to depend on theexact state restored when a fault is taken while reading the context.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Make the addrs_lock be per portMake the addrs_lock be per port, not per ipvlan dev.Initial code seems to be written in the assumption,that any address change must occur under RTNL.But it is not so for the case of IPv6. So1) Introduce per-port addrs_lock.2) It was needed to fix places where it was forgottento take lock (ipvlan_open/ipvlan_close)This appears to be a very minor problem though.Since it's highly unlikely that ipvlan_add_addr() willbe called on 2 CPU simultaneously. But nevertheless,this could cause:1) False-negative of ipvlan_addr_busy(): one interfaceiterated through all port->ipvlans + ipvlan->addrsunder some ipvlan spinlock, and another added IPunder its own lock. Though this is only possiblefor IPv6, since looks like only ipvlan_addr6_event() can becalled without rtnl_lock.2) Race since ipvlan_ht_addr_add(port) is called underdifferent ipvlan->addrs_lock locksThis should not affect performance, since add/remove IPis a rare situation and spinlock is not taken on fastpaths.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Allocate SSVE storage when restoring ZAThe code to restore a ZA context doesn't attempt to allocate the task'ssve_state before setting TIF_SME. Consequently, restoring a ZA contextcan place a task into an invalid state where TIF_SME is set but thetask's sve_state is NULL.In legitimate but uncommon cases where the ZA signal context was NOTcreated by the kernel in the context of the same task (e.g. if the taskis saved/restored with something like CRIU), we have no guarantee thatsve_state had been allocated previously. In these cases, userspace canenter streaming mode without trapping while sve_state is NULL, causing alater NULL pointer dereference when the kernel attempts to store theregister state:| # ./sigreturn-za| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000| Mem abort info:| ESR = 0x0000000096000046| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x06: level 2 translation fault| Data abort info:| ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000| CM = 0, WnR = 1, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000| Internal error: Oops: 0000000096000046 [#1] SMP| Modules linked in:| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT| Hardware name: linux,dummy-virt (DT)| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)| pc : sve_save_state+0x4/0xf0| lr : fpsimd_save_user_state+0xb0/0x1c0| sp : ffff80008070bcc0| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440| Call trace:| sve_save_state+0x4/0xf0 (P)| fpsimd_thread_switch+0x48/0x198| __switch_to+0x20/0x1c0| __schedule+0x36c/0xce0| schedule+0x34/0x11c| exit_to_user_mode_loop+0x124/0x188| el0_interrupt+0xc8/0xd8| __el0_irq_handler_common+0x18/0x24| el0t_64_irq_handler+0x10/0x1c| el0t_64_irq+0x198/0x19c| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)| ---[ end trace 0000000000000000 ]---Fix this by having restore_za_context() ensure that the task's sve_stateis allocated, matching what we do when taking an SME trap. Any liveSVE/SSVE state (which is restored earlier from a separate signalcontext) must be preserved, and hence this is not zeroed.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loopCurrently this is checked before running the pending work. Normally thisis quite fine, as work items either end up blocking (which will create anew worker for other items), or they complete fairly quickly. But syzbotreports an issue where io-wq takes seemingly forever to exit, and with abit of debugging, this turns out to be because it queues a bunch of big(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn'tsupport ->read_iter(), loop_rw_iter() ends up handling them. Each readreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch ofthese pending, processing the whole chain can take a long time. Easilylonger than the syzbot uninterruptible sleep timeout of 140 seconds.This then triggers a complaint off the io-wq exit path:INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa02738f749RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000caRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98There's really nothing wrong here, outside of processing these readswill take a LONG time. However, we can speed up the exit by checking theIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot willexit the ring after queueing up all of these reads. Then once the firstitem is processed, io-wq will simply cancel the rest. That should avoidsyzbot running into this complaint again.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpuFor i.MX8MQ platform, the ADB in the VPUMIX domain has no separate resetand clock enable bits, but is ungated and reset together with the VPUs.So we can't reset G1 or G2 separately, it may led to the system hang.Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.Let imx8mq_vpu_power_notifier() do really vpu reset.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix data-race warning and potential load/store tearingFix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packetwhich is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds();and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;The lockless accesses to these to values aren't actually a problem as theread only needs an approximate time of last transmission for the purposesof deciding whether or not the transmission of a keepalive packet iswarranted yet.Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bitarch.Fix both of these by switching to an unsigned int for ->last_tx_at and onlystoring the LSW of the time64_t. It can then be reconstructed at needprovided no more than 68 years has elapsed since the last transmission.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: provide a net pointer to __skb_flow_dissect()After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")we have to provide a net pointer to __skb_flow_dissect(),either via skb->dev, skb->sk, or a user provided pointer.In the following case, syzbot was able to cook a bare skb.WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: avoid one data-race in l2tp_tunnel_del_work()We should read sk->sk_socket only when dealing with kernel sockets.syzbot reported the following data-race:BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_releasewrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246value changed: 0xffff88811b818000 -> 0x0000000000000000
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: annotate data-race in ndisc_router_discovery()syzbot found that ndisc_router_discovery() could read and writein6_dev->ra_mtu without holding a lock [1]This looks fine, IFLA_INET6_RA_MTU is best effort.Add READ_ONCE()/WRITE_ONCE() to document the race.Note that we might also reject illegal MTU values(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.[1]BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discoveryread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...value changed: 0x00000000 -> 0xe5400659
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INITA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH keyinitialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127The issue is triggered when sctp_auth_asoc_init_active_key() fails insctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, thecommand sequence is currently:- SCTP_CMD_PEER_INIT- SCTP_CMD_TIMER_STOP (T1_INIT)- SCTP_CMD_TIMER_START (T1_COOKIE)- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)- SCTP_CMD_ASSOC_SHKEY- SCTP_CMD_GEN_COOKIE_ECHOIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, whileasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set bySCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULLto be queued by sctp_datamsg_from_user().Since command interpretation stops on failure, no COOKIE_ECHO should beensent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has alreadybeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. Asa result, the DATA chunk can be transmitted together with the COOKIE_ECHOin sctp_outq_flush_data(), leading to the observed issue.Similar to the other places where it calls sctp_auth_asoc_init_active_key()right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEYimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and startingT1_COOKIE. This ensures that if shared key generation fails, authenticatedDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,giving the client another chance to process INIT_ACK and retry key setup.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix a race issue related to the operation on bpf_bound_progs listThe netdevsim driver lacks a protection mechanism for operations on thebpf_bound_progs list. When the nsim_bpf_create_prog() performslist_add_tail, it is possible that nsim_bpf_destroy_prog() issimultaneously performs list_del. Concurrent operations on the list maylead to list corruption and trigger a kernel crash as follows:[ 417.290971] kernel BUG at lib/list_debug.c:62![ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 417.291007] Workqueue: events bpf_prog_free_deferred[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0[ 417.291088] PKRU: 55555554[ 417.291091] Call Trace:[ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim][ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0[ 417.291178] process_one_work+0x18a/0x3a0[ 417.291188] worker_thread+0x27b/0x3a0[ 417.291197] ? __pfx_worker_thread+0x10/0x10[ 417.291207] kthread+0xe5/0x120[ 417.291214] ? __pfx_kthread+0x10/0x10[ 417.291221] ret_from_fork+0x31/0x50[ 417.291230] ? __pfx_kthread+0x10/0x10[ 417.291236] ret_from_fork_asm+0x1a/0x30[ 417.291246] Add a mutex lock, to prevent simultaneous addition and deletion operationson the list.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: reset sparse-read state in osd_fault()When a fault occurs, the connection is abandoned, reestablished, and anypending operations are retried. The OSD client tracks the progress of asparse-read reply using a separate state machine, largely independent ofthe messenger's state.If a connection is lost mid-payload or the sparse-read state machinereturns an error, the sparse-read state is not reset. The OSD clientwill then interpret the beginning of a new reply as the continuation ofthe old one. If this makes the sparse-read machinery enter a failurestate, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on readTherefore, reset the sparse-read state in osd_fault(), ensuring retriesstart from a clean state.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add recursion protection in kernel stack trace recordingA bug was reported about an infinite recursion caused by tracing the rcuevents with the kernel stack trace trigger enabled. The stack trace codecalled back into RCU which then called the stack trace again.Expand the ftrace recursion protection to add a set of bits to protectevents from recursion. Each bit represents the context that the event isin (normal, softirq, interrupt and NMI).Have the stack trace code use the interrupt context to protect againstrecursion.Note, the bug showed an issue in both the RCU code as well as the tracingstacktrace code. This only handles the tracing stack trace side of thebug. The RCU fix will be handled separately.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: update last_gc only when GC has been performedCurrently last_gc is being updated everytime a new connection istracked, that means that it is updated even if a GC wasn't performed.With a sufficiently high packet rate, it is possible to always bypassthe GC, causing the list to grow infinitely.Update the last_gc value only when a GC has been actually performed.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Subtract size of xdp_frame from allowed metadata sizeThe xdp_frame structure takes up part of the XDP frame headroom,limiting the size of the metadata. However, in bpf_test_run, we don'ttake this into account, which makes it possible for userspace to supplya metadata size that is too large (taking up the entire headroom).If userspace supplies such a large metadata size in live packet mode,the xdp_update_frame_from_buff() call in xdp_test_run_init_page() callwill fail, after which packet transmission proceeds with anuninitialised frame structure, leading to the usual Bad Stuff.The commit in the Fixes tag fixed a related bug where the second checkin xdp_update_frame_from_buff() could fail, but did not add anyadditional constraints on the metadata size. Complete the fix by addingan additional check on the metadata size. Reorder the checks slightly tomake the logic clearer and add a comment.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: send: check for inline extents in range_is_hole_in_parent()Before accessing the disk_bytenr field of a file extent item we needto check if we are dealing with an inline extent.This is because for inline extents their data starts at the offset ofthe disk_bytenr field. So accessing the disk_bytenrmeans we are accessing inline data or in case the inline data is lessthan 8 bytes we can actually cause an invalidmemory access if this inline extent item is the first item in the leafor access metadata from other items.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failureWhen a DAMOS-scheme DAMON sysfs directory setup fails after setup ofaccess_pattern/ directory, subdirectories of access_pattern/ directory arenot cleaned up. As a result, DAMON sysfs interface is nearly broken untilthe system reboots, and the memory for the unremoved directory is leaked.Cleanup the directories under such failures.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: cleanup attrs subdirs on context dir setup failureWhen a context DAMON sysfs directory setup is failed after setup of attrs/directory, subdirectories of attrs/ directory are not cleaned up. As aresult, DAMON sysfs interface is nearly broken until the system reboots,and the memory for the unremoved directory is leaked.Cleanup the directories under such failures.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix segmentation of forwarding fraglist GROThis patch enhances GSO segment handling by properly checkingthe SKB_GSO_DODGY flag for frag_list GSO packets, addressinglow throughput issues observed when a station accesses IPv4servers via hotspots with an IPv6-only upstream interface.Specifically, it fixes a bug in GSO segmentation when forwardingGRO packets containing a frag_list. The function skb_segment_listcannot correctly process GRO skbs that have been converted by XLAT,since XLAT only translates the header of the head skb. Consequently,skbs in the frag_list may remain untranslated, resulting in protocolinconsistencies and reduced throughput.To address this, the patch explicitly sets the SKB_GSO_DODGY flagfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSOpackets as potentially modified after protocol translation. As aresult, GSO segmentation will avoid using skb_segment_list andinstead falls back to skb_segment for packets with the SKB_GSO_DODGYflag. This ensures that only safe and fully translated frag_listpackets are processed by skb_segment_list, resolving protocolinconsistencies and improving throughput when forwarding GRO packetsconverted by XLAT.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not strictly require dirty metadata threshold for metadata writepages[BUG]There is an internal report that over 1000 processes arewaiting at the io_schedule_timeout() of balance_dirty_pages(), causinga system hang and trigger a kernel coredump.The kernel is v6.4 kernel based, but the root problem still applies toany upstream kernel before v6.18.[CAUSE]From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup.So that means the only way to reduce the dirty pages of that cgroup isto writeback the dirty pages of btrfs btree inode, and only after thatthose processes can exit balance_dirty_pages().Now back to the btrfs part, btree_writepages() is responsible forwriting back dirty btree inode pages.The problem here is, there is a btrfs internal threshold that if thebtree inode's dirty bytes are below the 32M threshold, it will notdo any writeback.This behavior is to batch as much metadata as possible so we won't writeback those tree blocks and then later re-COW them again for anothermodification.This internal 32MiB is higher than the existing dirty page size (28MiB),meaning no writeback will happen, causing a deadlock between btrfs andcgroup:- Btrfs doesn't want to write back btree inode until more dirty pages- Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced.Thanks Jan Kara a lot for the analysis of the root cause.[ENHANCEMENT]Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on thebtree_inode"), btrfs btree inode pages will only be charged to the rootcgroup which should have a much larger limit than btrfs' 32MiBthreshold.So it should not affect newer kernels.But for all current LTS kernels, they are all affected by this problem,and backporting the whole AS_KERNEL_FILE may not be a good idea.Even for newer kernels I still think it's a good idea to getrid of the internal threshold at btree_writepages(), since for most casescgroup/MM has a better view of full system memory usage than btrfs' fixedthreshold.For internal callers using btrfs_btree_balance_dirty() since thatfunction is already doing internal threshold check, we don't need tobother them.But for external callers of btree_writepages(), just respect theirrequests and write back whatever they want, ignoring the internalbtrfs threshold to avoid such deadlock on btree inode dirty pagebalancing.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Fix memory leak in octep_device_setup()In octep_device_setup(), if octep_ctrl_net_init() fails, the functionreturns directly without unmapping the mapped resources and freeing theallocated configuration memory.Fix this by jumping to the unsupported_dev label, which performs thenecessary cleanup. This aligns with the error handling logic of otherpaths in this function.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:rocker: fix memory leak in rocker_world_port_post_fini()In rocker_world_port_pre_init(), rocker_port->wpriv is allocated withkzalloc(wops->port_priv_size, GFP_KERNEL). However, inrocker_world_port_post_fini(), the memory is only freed whenwops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);Since rocker_ofdpa_ops does not implement port_post_fini callback(it is NULL), the wpriv memory allocated for each port is never freedwhen ports are removed. This leads to a memory leak ofsizeof(struct ofdpa_port) bytes per port on every device removal.Fix this by always calling kfree(rocker_port->wpriv) regardless ofwhether the port_post_fini callback exists.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:flex_proportions: make fprop_new_period() hardirq safeBernd has reported a lockdep splat from flexible proportions code that isessentially complaining about the following race:run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - sees odd sequence so loops indefinitelyNote that a deadlock like this is only possible if the bdi has configuredmaximum fraction of writeout throughput which is very rare in general butfrequent for example for FUSE bdis. To fix this problem we have to makesure write section of the sequence counter is irqsafe.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()When the socket is closed while in TCP_LISTEN a callback is run toflush all outstanding packets, which in turns callsnvmet_tcp_listen_data_ready() with the sk_callback_lock held.So we need to check if we are in TCP_LISTEN before attemptingto get the sk_callback_lock() to avoid a deadlock.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domainsFix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix oops due to invalid pointer for kfree() in parse_longname()This fixes a kernel oops when reading ceph snapshot directories (.snap),for example by simply running `ls /mnt/my_ceph/.snap`.The variable str is guarded by __free(kfree), but advanced by one forskipping the initial '_' in snapshot names. Thus, kfree() is calledwith an invalid pointer. This patch removes the need for advancing thepointer so kfree() is called with correct memory pointer.Steps to reproduce:1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)2. Add cephfs mount to fstab$ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" >> /etc/fstab3. Reboot the system$ systemctl reboot4. Check if it's really mounted$ mount | grep stuff5. List snapshots (expected 63 snapshots on my system)$ ls /mnt/test/stuff/.snapNow ls hangs forever and the kernel log shows the oops.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: annotate data-races around slave->last_rxslave->last_rx and slave->target_last_arp_rx[...] can be read and writtenlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.syzbot reported:BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validatewrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410...write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline]...value changed: 0x0000000100005365 -> 0x0000000100005366
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmware: Fix hypercall clobbersFedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ...because the QEMU VMware mouse emulation is buggy, and clears the top 32bits of %rdi that the kernel kept a pointer in.The QEMU vmmouse driver saves and restores the register state in a"uint32_t data[6];" and as a result restores the state with the highbits all cleared.RDI originally contained the value of a valid kernel stack address(0xff5eeb3240003e54). After the vmware hypercall it now contains0x40003e54, and we get a page fault as a result when it is dereferenced.The proper fix would be in QEMU, but this works around the issue in thekernel to keep old setups working, when old kernels had not happened tokeep any state in %rdi over the hypercall.In theory this same issue exists for all the hypercalls in the vmmousedriver; in practice it has only been seen with vmware_hypercall3() andvmware_hypercall4(). For now, just mark RDI/RSI as clobbered for thosetwo calls. This should have a minimal effect on code generation overallas it should be rare for the compiler to want to make RDI/RSI liveacross hypercalls.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()In iscsit_dec_conn_usage_count(), the function calls complete() whileholding the conn->conn_usage_lock. As soon as complete() is invoked, thewaiter (such as iscsit_close_connection()) may wake up and proceed to freethe iscsit_conn structure.If the waiter frees the memory before the current thread reachesspin_unlock_bh(), it results in a KASAN slab-use-after-free as the functionattempts to release a lock within the already-freed connection structure.Fix this by releasing the spinlock before calling complete().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: add chann_lock to protect ksmbd_chann_list xarrayksmbd_chann_list xarray lacks synchronization, allowing use-after-free inmulti-channel sessions (between lookup_chann_list() and ksmbd_chann_del).Adds rw_semaphore chann_lock to struct ksmbd_session and protectsall xa_load/xa_store/xa_erase accesses.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix potential NULL pointer dereference in header processingIf siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(),qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data()dereferences qp->rx_fpdu->more_ddp_segs without checking, whichmay lead to a NULL pointer deref. Only check more_ddp_segs whenrx_fpdu is present.KASAN splat:[ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7][ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix memory allocation in nvme_pr_read_keys()nvme_pr_read_keys() takes num_keys from userspace and uses it tocalculate the allocation size for rse via struct_size(). The upperlimit is PR_KEYS_MAX (64K).A malicious or buggy userspace can pass a large num_keys value thatresults in a 4MB allocation attempt at most, causing a warning inthe page allocator when the order exceeds MAX_PAGE_ORDER.To fix this, use kvzalloc() instead of kzalloc().This bug has the same reasoning and fix with the patch below:https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/Warning log:WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272Modules linked in:CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0dRSP: 0018:ffffc90000fcf450 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0Call Trace: alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486 alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557 ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598 __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629 __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245 blkdev_pr_read_keys block/ioctl.c:456 [inline] blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730 blkdev_ioctl+0x299/0x700 block/ioctl.c:786 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583 x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fb893d3108dCode: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108dRDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: secure_seq: add back ports to TS offsetThis reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")tcp_tw_recycle went away in 2017.Zhouyan Deng reported off-path TCP source port leakage viaSYN cookie side-channel that can be fixed in multiple ways.One of them is to bring back TCP ports in TS offset randomization.As a bonus, we perform a single siphash() computationto provide both an ISN and a TS offset.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Compile tested only. Issue found using code review.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Also, decrement i in the devlink_alloc failure path to point to thelast successfully allocated index.Compile tested only. Issue found using code review.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rw: free potentially allocated iovec on cache put failureIf a read/write request goes through io_req_rw_cleanup() and has anallocated iovec attached and fails to put to the rw_cache, then it mayend up with an unaccounted iovec pointer. Have io_rw_recycle() returnwhether it recycled the request or not, and use that to gauge whether tofree a potential iovec or not.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writesDuring SPO tests, when mounting F2FS, an -EINVAL error was returned fromf2fs_recover_inode_page. The issue occurred under the following scenarioThread A Thread Bf2fs_ioc_commit_atomic_write - f2fs_do_sync_file // atomic = true - f2fs_fsync_node_pages : last_folio = inode folio : schedule before folio_lock(last_folio) f2fs_write_checkpoint - block_operations// writeback last_folio - schedule before f2fs_flush_nat_entries : set_fsync_mark(last_folio, 1) : set_dentry_mark(last_folio, 1) : folio_mark_dirty(last_folio) - __write_node_folio(last_folio) : f2fs_down_read(&sbi->node_write)//block - f2fs_flush_nat_entries : {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED) - unblock_operations : f2fs_up_write(&sbi->node_write) f2fs_write_checkpoint//return : f2fs_do_write_node_page()f2fs_ioc_commit_atomic_write//return SPOThread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio hasalready been written once. However, the {struct nat_entry}->flag did nothave the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) andwrite last_folio again after Thread B finishes f2fs_write_checkpoint.After SPO and reboot, it was detected that {struct node_info}->blk_addrwas not NULL_ADDR because Thread B successfully write the checkpoint.This issue only occurs in atomic write scenarios. For regular filefsync operations, the folio must be dirty. Ifblock_operations->f2fs_sync_node_pages successfully submit the foliowrite, this path will not be executed. Otherwise, thef2fs_write_checkpoint will need to wait for the folio write submissionto complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, thesituation where f2fs_need_dentry_mark checks that the {structnat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write hasalready been submitted, will not occur.Therefore, for atomic file fsync, sbi->node_write should be acquiredthrough __write_node_folio to ensure that the IS_CHECKPOINTED flagcorrectly indicates that the checkpoint write has been completed.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocksAs Paolo said earlier [1]:"Since the blamed commit below, classify can return TC_ACT_CONSUMED whilethe current skb being held by the defragmentation engine. As reported byGangMin Kim, if such packet is that may cause a UaF when the defrag enginelater on tries to tuch again such packet."act_ct was never meant to be used in the egress path, however some usersare attaching it to egress today [2]. Attempting to reach a middleground, we noticed that, while most qdiscs are not handlingTC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, weaddress the issue by only allowing act_ct to bind to clsact/ingressqdiscs and shared blocks. That way it's still possible to attach act_ct toegress (albeit only with clsact).[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/[2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labelsIDLETIMER revision 0 rules reuse existing timers by label and always callmod_timer() on timer->timer.If the label was created first by revision 1 with XT_IDLETIMER_ALARM,the object uses alarm timer semantics and timer->timer is never initialized.Reusing that object from revision 0 causes mod_timer() on an uninitializedtimer_list, triggering debugobjects warnings and possible panic whenpanic_on_warn=1.Fix this by rejecting revision 0 rule insertion when an existing timer withthe same label is of ALARM type.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libexpat1 < 2.7.1-150700.3.9.2 (version in image is 2.7.1-150700.3.6.1).
-
Description: Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0110-150500.20.43.1 (version in image is 9.1.1629-150500.20.38.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: A flaw was found in GnuTLS. This vulnerability allows a denial of service (DoS) by excessive CPU (Central Processing Unit) and memory consumption via specially crafted malicious certificates containing a large number of name constraints and subject alternative names (SANs).
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libgnutls30 < 3.8.3-150600.4.17.1 (version in image is 3.8.3-150600.4.12.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:md: suspend array while updating raid_disks via sysfsIn raid1_reshape(), freeze_array() is called before modifying the r1biomemory pool (conf->r1bio_pool) and conf->raid_disks, andunfreeze_array() is called after the update is completed.However, freeze_array() only waits until nr_sync_pending and(nr_pending - nr_queued) of all buckets reaches zero. When an I/O erroroccurs, nr_queued is increased and the corresponding r1bio is queued toeither retry_list or bio_end_io_list. As a result, freeze_array() mayunblock before these r1bios are released.This can lead to a situation where conf->raid_disks and the mempool havealready been updated while queued r1bios, allocated with the oldraid_disks value, are later released. Consequently, free_r1bio() mayaccess memory out of bounds in put_all_bios() and release r1bios of thewrong size to the new mempool, potentially causing issues with themempool as well.Since only normal I/O might increase nr_queued while an I/O error occurs,suspending the array avoids this issue.Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspendsthe array. Therefore, we suspend the array when updating raid_disksvia sysfs to avoid this issue too.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: 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: In the Linux kernel, the following vulnerability has been resolved:net: fix memory leak in skb_segment_list for GRO packetsWhen skb_segment_list() is called during packet forwarding, it handlespackets that were aggregated by the GRO engine.Historically, the segmentation logic in skb_segment_list assumes thatindividual segments are split from a parent SKB and may need to carrytheir own socket memory accounting. Accordingly, the code transferstruesize from the parent to the newly created segments.Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), thistruesize subtraction in skb_segment_list() was valid because fragmentsstill carry a reference to the original socket.However, commit ed4cccef64c1 ("gro: fix ownership transfer") changedthis behavior by ensuring that fraglist entries are explicitlyorphaned (skb->sk = NULL) to prevent illegal orphaning later in thestack. This change meant that the entire socket memory charge remainedwith the head SKB, but the corresponding accounting logic inskb_segment_list() was never updated.As a result, the current code unconditionally adds each fragment'struesize to delta_truesize and subtracts it from the parent SKB. Sincethe fragments are no longer charged to the socket, this subtractionresults in an effective under-count of memory when the head is freed.This causes sk_wmem_alloc to remain non-zero, preventing socketdestruction and leading to a persistent memory leak.The leak can be observed via KMEMLEAK when tearing down the networkingenvironment:unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLISTpackets constructed by GRO, the truesize adjustment is removed.The call to skb_release_head_state() must be preserved. As documented incommit cf673ed0e057 ("net: fix fraglist segmentation reference countleak"), it is still required to correctly drop references to SKBextensions that may be overwritten during __copy_skb_header().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Sanitize payload size to prevent member overflowIn qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_sizereported by firmware is used to calculate the copy length intoitem->iocb. However, the iocb member is defined as a fixed-size 64-bytearray within struct purex_item.If the reported frame_size exceeds 64 bytes, subsequent memcpy calls willoverflow the iocb member boundary. While extra memory might be allocated,this cross-member write is unsafe and triggers warnings underCONFIG_FORTIFY_SOURCE.Fix this by capping total_bytes to the size of the iocb member (64 bytes)before allocation and copying. This ensures all copies remain within thebounds of the destination structure member.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix use-after-free due to enslave fail after slave array updateFix a use-after-free which happens due to enslave failure after the newslave has been added to the array. Since the new slave can be used for Tximmediately, we can use it after it has been freed by the enslave errorcleanup path which frees the allocated slave memory. Slave update array issupposed to be called last when further enslave failures are not expected.Move it after xdp setup to avoid any problems.It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummyThen run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? __pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix use-after-free in driver_override_show()The driver_override_show() function reads the driver_override stringwithout holding the device_lock. However, driver_override_store() usesdriver_set_override(), which modifies and frees the string while holdingthe device_lock.This can result in a concurrent use-after-free if the string is freedby the store function while being read by the show function.Fix this by holding the device_lock around the read operation.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix __perf_event_overflow() vs perf_remove_from_context() raceMake sure that __perf_event_overflow() runs with IRQs disabled for allpossible callchains. Specifically the software events can end up runningit with only preemption disabled.This opens up a race vs perf_event_exit_event() and friends that will goand free various things the overflow path expects to be present, likethe BPF program.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libz1 < 1.2.13-150500.4.6.1 (version in image is 1.2.13-150500.4.3.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0110-150500.20.43.1 (version in image is 9.1.1629-150500.20.38.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.
Packages affected:
- 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: Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.
Packages affected:
- 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: Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.
Packages affected:
- 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: Vim is an open source, command line text editor. From 9.1.0011 to before 9.2.0137, Vim's NFA regex compiler, when encountering a collection containing a combining character as the endpoint of a character range (e.g. [0-0\u05bb]), incorrectly emits the composing bytes of that character as separate NFA states. This corrupts the NFA postfix stack, resulting in NFA_START_COLL having a NULL out1 pointer. When nfa_max_width() subsequently traverses the compiled NFA to estimate match width for the look-behind assertion, it dereferences state->out1->out without a NULL check, causing a segmentation fault. This vulnerability is fixed in 9.2.0137.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim > 0-0 (version in image is 9.1.1629-150500.20.38.1).
-
Description: Unknown.
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: A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftp_extensions_get_name/sftp_extensions_get_data of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config > 0-0 (version in image is 0.9.8-150600.11.6.1).
-
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix devlink reload call traceCommit 4da71a77fc3b ("ice: read internal temperature sensor") introducedinternal temperature sensor reading via HWMON. ice_hwmon_init() was addedto ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As aresult if devlink reload is used to reinit the device and then the driveris removed, a call trace can occur.BUG: unable to handle page fault for address: ffffffffc0fd4b5dCall Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60The call trace repeats approximately every 10 minutes when systemmonitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfsattributes that reference freed module memory.The sequence is:1. Driver load, ice_hwmon_init() gets called from ice_init_feature()2. Devlink reload down, flow does not call ice_remove()3. Devlink reload up, ice_hwmon_init() gets called from ice_init_feature() resulting in a second instance4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the first hwmon instance orphaned with dangling pointerFix this by moving ice_hwmon_exit() from ice_remove() toice_deinit_features() to ensure proper cleanup symmetry withice_hwmon_init().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config < 0.9.8-150600.11.9.1 (version in image is 0.9.8-150600.11.6.1).
-
Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't log conflicting inode if it's a dir moved in the current transactionWe can't log a conflicting inode if it's a directory and it was movedfrom one parent directory to another parent directory in the currenttransaction, as this can result an attempt to have a directory withtwo hard links during log replay, one for the old parent directory andanother for the new parent directory.The following scenario triggers that issue:1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory;2) We move "dir1" to some other directory;3) We create a file with the name "dir1" in directory inode A;4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1";5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name();6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory);7) We have a power failure;8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1".As a result after log replay finishes when we trigger writeback of thesubvolume tree's extent buffers, the tree check will detect that we havea directory a hard link count of 2 and we get a mount failure.The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [ 3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [ 3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [ 3845.737816] location key (257 1 0) type 2 [---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved: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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: restore destructor on submit failurehandshake_req_submit() replaces sk->sk_destruct but never restores it whensubmission fails before the request is hashed. handshake_sk_destruct() thenreturns early and the original destructor never runs, leaking the socket.Restore sk_destruct on the error path.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock in wait_current_trans() due to ignored transaction typeWhen wait_current_trans() is called during start_transaction(), itcurrently waits for a blocked transaction without considering whetherthe given transaction type actually needs to wait for that particulartransaction state. The btrfs_blocked_trans_types[] array already defineswhich transaction types should wait for which transaction states, butthis check was missing in wait_current_trans().This can lead to a deadlock scenario involving two transactions andpending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction BThis can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!)Task bstore_kv_sync in btrfs_commit_transaction waiting for orderedextents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30Fix this by passing the transaction type to wait_current_trans() andchecking btrfs_blocked_trans_types[cur_trans->state] against the giventype before deciding to wait. This ensures that transaction types whichare allowed to join during certain blocked states will not unnecessarilywait and cause deadlocks.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not free data reservation in fallback from inline due to -ENOSPCIf we fail to create an inline extent due to -ENOSPC, we will attempt togo through the normal COW path, reserve an extent, create an orderedextent, etc. However we were always freeing the reserved qgroup data,which is wrong since we will use data. Fix this by freeing the reservedqgroup data in __cow_file_range_inline() only if we are not doing thefallback (ret is <= 0).
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()The for_each_available_child_of_node() calls of_node_put() torelease child_np in each success loop. After breaking from theloop with the child_np has been released, the code will jump tothe put_child label and will call the of_node_put() again if thedevm_request_threaded_irq() fails. These cause a double free bug.Fix by returning directly to avoid the duplicate of_node_put().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix a deadlock when returning a delegation during open()Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935The issue is that the delegreturn is being asked to wait for a layoutreturn that cannot complete because a state recovery was initiated. Thestate recovery cannot complete until the open() finishes processing thedelegations it was given.The solution is to propagate the existing flags that indicate anon-blocking call to the function pnfs_roc(), so that it knows not towait in this situation.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a deadlock involving nfs_release_folio()Wang Zhaolong reports a deadlock involving NFSv4.1 state recoverywaiting on kthreadd, which is attempting to reclaim memory by callingnfs_release_folio(). The latter cannot make progress due to staterecovery being needed.It seems that the only safe thing to do here is to kick off a writebackof the folio, without waiting for completion, or else kicking off anasynchronous commit.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix potential underflow in virtio_transport_get_credit()The credit calculation in virtio_transport_get_credit() uses unsignedarithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);If the peer shrinks its advertised buffer (peer_buf_alloc) while bytesare in flight, the subtraction can underflow and produce a largepositive value, potentially allowing more data to be queued than thepeer can handle.Reuse virtio_transport_has_space() which already handles this case andadd a comment to make it clear why we are doing that.[Stefano: use virtio_transport_has_space() instead of duplicating the code][Stefano: tweak the commit message]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_agThis is more of a preventive patch to make the code more consistent andto prevent possible exploits that employ child qlen manipulations on qfq.use cl_is_active instead of relying on the child qdisc's qlen to determineclass activation.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Wake up the error handler when final completions race against each otherThe fragile ordering between marking commands completed or failed sothat the error handler only wakes when the last running commandcompletes or times out has race conditions. These race conditions cancause the SCSI layer to fail to wake the error handler, leaving I/Othrough the SCSI host stuck as the error state cannot advance.First, there is an memory ordering issue within scsi_dec_host_busy().The write which clears SCMD_STATE_INFLIGHT may be reordered with readscounting in scsi_host_busy(). While the local CPU will see its ownwrite, reordering can allow other CPUs in scsi_dec_host_busy() orscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU tosee a host busy equal to the host_failed count.This race condition can be prevented with a memory barrier on the errorpath to force the write to be visible before counting host busycommands.Second, there is a general ordering issue with scsi_eh_inc_host_failed(). Bycounting busy commands before incrementing host_failed, it can race with afinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() doesnot see host_failed incremented but scsi_eh_inc_host_failed() counts busycommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),resulting in neither waking the error handler task.This needs the call to scsi_host_busy() to be moved after host_failed isincremented to close the race condition.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Don't clobber irqfd routing type when deassigning irqfdWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ'srouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, tohandle a concurrent routing update, verify that the irqfd is still activebefore consuming the routing information. As evidenced by the x86 andarm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),clobbering the entry type without notifying arch code is surprising anderror prone.As a bonus, checking that the irqfd is active provides a convenientlocation for documenting _why_ KVM must not consume the routing entry foran irqfd that is in the process of being deassigned: once the irqfd isdeleted from the list (which happens *before* the eventfd is detached), itwill no longer receive updates via kvm_irq_routing_update(), and so KVMcould deliver an event using stale routing information (relative toKVM_SET_GSI_ROUTING returning to userspace).As an even better bonus, explicitly checking for the irqfd being activefixes a similar bug to the one the clobbering is trying to prevent: if anirqfd is deactivated, and then its routing is changed,kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()(because the irqfd isn't in the list). And so if the irqfd is in bypassmode, IRQs will continue to be posted using the old routing information.As for kvm_arch_irq_bypass_del_producer(), clobbering the routing typeresults in KVM incorrectly keeping the IRQ in bypass mode, which isespecially problematic on AMD as KVM tracks IRQs that are being posted toa vCPU in a list whose lifetime is tied to the irqfd.Without the help of KASAN to detect use-after-free, the most commonsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due tothe memory for irqfd structure being re-allocated and zeroed, resultingin irqfd->irq_bypass_data being NULL when read byavic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]---If AVIC is inhibited when the irfd is deassigned, the bug will manifest aslist corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa---truncated---
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix PTP NULL pointer dereference during VSI rebuildFix race condition where PTP periodic work runs while VSI is beingrebuilt, accessing NULL vsi->rx_rings.The sequence was:1. ice_ptp_prepare_for_reset() cancels PTP work2. ice_ptp_rebuild() immediately queues PTP work3. VSI rebuild happens AFTER ice_ptp_rebuild()4. PTP work runs and accesses NULL vsi->rx_ringsFix: Keep PTP work cancelled during rebuild, only queue it afterVSI rebuild completes in ice_rebuild().Added ice_ptp_queue_work() helper function to encapsulate the logicfor queuing PTP work, ensuring it's only queued when PTP is supportedand the state is ICE_PTP_READY.Error log:[ 121.392544] ice 0000:60:00.1: PTP reset successful[ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 121.392712] #PF: supervisor read access in kernel mode[ 121.392720] #PF: error_code(0x0000) - not-present page[ 121.392727] PGD 0[ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI[ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)[ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC[ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice][ 121.393042] Call Trace:[ 121.393047] [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice][ 121.393202] kthread_worker_fn+0xa2/0x260[ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice][ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10[ 121.393371] kthread+0x10d/0x230[ 121.393382] ? __pfx_kthread+0x10/0x10[ 121.393393] ret_from_fork+0x273/0x2b0[ 121.393407] ? __pfx_kthread+0x10/0x10[ 121.393417] ret_from_fork_asm+0x1a/0x30[ 121.393432]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: Fix race condition in espintcp_close()This issue was discovered during a code audit.After cancel_work_sync() is called from espintcp_close(),espintcp_tx_work() can still be scheduled from paths such asthe Delayed ACK handler or ksoftirqd.As a result, the espintcp_tx_work() worker may dereference afreed espintcp ctx or sk.The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work);To prevent this race condition, cancel_work_sync() isreplaced with disable_work_sync().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Fix race condition in tls_sw_cancel_work_tx()This issue was discovered during a code audit.After cancel_delayed_work_sync() is called from tls_sk_proto_close(),tx_work_handler() can still be scheduled from paths such as theDelayed ACK handler or ksoftirqd.As a result, the tx_work_handler() worker may dereference a freedTLS object.The following is a simple race scenario: cpu0 cpu1tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0);To prevent this race condition, cancel_delayed_work_sync() isreplaced with disable_delayed_work_sync().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: add proper RCU protection to /proc/net/ptypeYin Fengwei reported an RCU stall in ptype_seq_show() and provideda patch.Real issue is that ptype_seq_next() and ptype_seq_show() violateRCU rules.ptype_seq_show() runs under rcu_read_lock(), and reads pt->devto get device name without any barrier.At the same time, concurrent writers can remove a packet_type structure(which is correctly freed after an RCU grace period) and clear pt->devwithout an RCU grace period.Define ptype_iter_state to carry a dev pointer along seq_net_private:struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch};We need to record the device pointer in ptype_get_idx() andptype_seq_next() so that ptype_seq_show() is safe againstconcurrent pt->dev changes.We also need to add full RCU protection in ptype_seq_next().(Missing READ_ONCE() when reading list.next values)Many thanks to Dong Chenchen for providing a repro.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always walk all pending catchall elementsDuring transaction processing we might have more than one catchall element:1 live catchall element and 1 pending element that is coming as part of thenew batch.If the map holding the catchall elements is also going away, itsrequired to toggle all catchall elements and not just the first viablecandidate.Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a redirect to a second URL, curl could leak that token to the secondhostname under some circumstances.If the hostname that the first request is redirected to has information in theused .netrc file, with either of the `machine` or `default` keywords, curlwould pass on the bearer token set for the first host also to the second one.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl < 8.14.1-150700.7.14.1 (version in image is 8.14.1-150700.7.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject new transactions if the fs is fully read-only[BUG]There is a bug report where a heavily fuzzed fs is mounted with allrescue mount options, which leads to the following warnings duringunmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Since rescue mount options will mark the full fs read-only, there shouldbe no new transaction triggered.But during unmount we will evict all inodes, which can trigger a newtransaction, and triggers warnings on a heavily corrupted fs.[CAUSE]Btrfs allows new transaction even on a read-only fs, this is to allowlog replay happen even on read-only mounts, just like what ext4/xfs do.However with rescue mount options, the fs is fully read-only and cannotbe remounted read-write, thus in that case we should also reject any newtransactions.[FIX]If we find the fs has rescue mount options, we should treat the fs aserror, so that no new transaction can be started.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to aserver, even if the new request uses different credentials for the HTTP proxy.The proper behavior is to create or use a separate connection.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl < 8.14.1-150700.7.14.1 (version in image is 8.14.1-150700.7.11.1).
-
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
- sle-module-containers-release == 15.7 (version in image is 15.7-150700.28.1).
- containerd-ctr > 0-0 (version in image is 1.7.29-150000.128.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: ncurses v6.5 and v6.4 are vulnerable to Buffer Overflow in progs/infocmp.c, function analyze_string().
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libncurses6 > 0-0 (version in image is 6.1-150000.5.30.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Avoid creating sub-groups asynchronouslyThe asynchronous creation of sub-groups by a delayed work could lead to aNULL pointer dereference when the driver directory is removed before thework completes.The crash can be easily reproduced with the following commands: # cd /sys/kernel/config/pci_ep/functions/pci_epf_test # for i in {1..20}; do mkdir test && rmdir test; done BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfs_register_group+0x3d/0x190 pci_epf_cfs_work+0x41/0x110 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0Fix this issue by using configfs_add_default_group() API which does nothave the deadlock problem as configfs_register_group() and does not requirethe delayed work handler.[mani: slightly reworded the description and added stable list]
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leakIn gs_can_open(), the URBs for USB-in transfers are allocated, added to theparent->rx_submitted anchor and submitted. In the complete callbackgs_usb_receive_bulk_callback(), the URB is processed and resubmitted. Ings_can_close() the URBs are freed by callingusb_kill_anchored_urbs(parent->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in gs_can_close().Fix the memory leak by anchoring the URB in thegs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ife: avoid possible NULL dereftcf_ife_encode() must make sure ife_encode() does not return NULL.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_listWhen the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() isset to false, the driver may request the PMAC_ID from the firmware of thenetwork card, and this function will store that PMAC_ID at the providedaddress pmac_id. This is the contract of this function.However, there is a location within the driver where bothpmac_id_valid == false and pmac_id == NULL are being passed. This couldresult in dereferencing a NULL pointer.To resolve this issue, it is necessary to pass the address of a stubvariable to the function.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers areallocated, added to the priv->rx_submitted anchor and submitted. In thecomplete callback usb_8dev_read_bulk_callback(), the URBs are processed andresubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed bycalling usb_kill_anchored_urbs(&priv->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in theusb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix NULL pointer dereference in ice_vsi_set_napi_queuesAdd NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashesduring resume from suspend when rings[q_idx]->q_vector is NULL.Tested adaptor:60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]SR-IOV state: both disabled and enabled can reproduce this issue.kernel version: v6.18Reproduce steps:Boot up and execute suspend like systemctl suspend or rtcwake.Log:<1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040<1>[ 231.444052] #PF: supervisor read access in kernel mode<1>[ 231.444484] #PF: error_code(0x0000) - not-present page<6>[ 231.444913] PGD 0 P4D 0<4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI<4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170<4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89<4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202<4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010<4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000<4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000<4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000<4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000<4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0<4>[ 231.451629] PKRU: 55555554<4>[ 231.452076] Call Trace:<4>[ 231.452549] <4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]<4>[ 231.453482] ice_resume+0xfd/0x220 [ice]<4>[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10<4>[ 231.454425] pci_pm_resume+0x8c/0x140<4>[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10<4>[ 231.455347] dpm_run_callback+0x5f/0x160<4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170<4>[ 231.456244] device_resume+0x177/0x270<4>[ 231.456708] dpm_resume+0x209/0x2f0<4>[ 231.457151] dpm_resume_end+0x15/0x30<4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0<4>[ 231.458054] enter_state+0x10e/0x570Add defensive checks for both the ring pointer and its q_vectorbefore dereferencing, allowing the system to resume successfully even whenq_vectors are unmapped.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: TC, delete flows only for existing peersWhen deleting TC steering flows, iterate only over actual devcompeers instead of assuming all possible ports exist. This avoidstouching non-existent peers and ensures cleanup is limited todevices the driver is currently connected to. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress] __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320 ? __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1ef/0x230 ? copy_msghdr_from_user+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).
-
Description: An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libsqlite3-0 > 0-0 (version in image is 3.51.2-150000.3.36.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: add bounds check for if_id in IRQ handlerThe IRQ handler extracts if_id from the upper 16 bits of the hardwarestatus register and uses it to index into ethsw->ports[] withoutvalidation. Since if_id can be any 16-bit value (0-65535) but the portsarray is only allocated with sw_attr.num_ifs elements, this can lead toan out-of-bounds read potentially.Add a bounds check before accessing the array, consistent with theexisting validation in dpaa2_switch_rx().
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zeroThe driver allocates arrays for ports, FDBs, and filter blocks usingkcalloc() with ethsw->sw_attr.num_ifs as the element count. When thedevice reports zero interfaces (either due to hardware configurationor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)instead of NULL.Later in dpaa2_switch_probe(), the NAPI initialization unconditionallyaccesses ethsw->ports[0]->netdev, which attempts to dereferenceZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.Add a check to ensure num_ifs is greater than zero after retrievingdevice attributes. This prevents the zero-sized allocations andsubsequent invalid pointer dereference.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- vim < 9.2.0110-150500.20.43.1 (version in image is 9.1.1629-150500.20.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: Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.
Packages affected:
- 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: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config < 0.9.8-150600.11.9.1 (version in image is 0.9.8-150600.11.6.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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In 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: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: 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:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid chain re-validation if possibleHamza Mahfooz reports cpu soft lock-ups innft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547][..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables][..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables][..]Currently nf_tables will traverse the entire table (chain graph), startingfrom the entry points (base chains), exploring all possible paths(chain jumps). But there are cases where we could avoid revalidation.Consider:1 input -> j2 -> j32 input -> j2 -> j33 input -> j1 -> j2 -> j3Then the second rule does not need to revalidate j2, and, by extension j3,because this was already checked during validation of the first rule.We need to validate it only for rule 3.This is needed because chain loop detection also ensures we do not exceedthe jump stack: Just because we know that j2 is cycle free, its last jumpmight now exceed the allowed stack size. We also need to update allreachable chains with the new largest observed call depth.Care has to be taken to revalidate even if the chain depth won't be anissue: chain validation also ensures that expressions are not called frominvalid base chains. For example, the masquerade expression can only becalled from NAT postrouting base chains.Therefore we also need to keep record of the base chain context (type,hooknum) and revalidate if the chain becomes reachable from a differenthook location.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: add fchmodat2() to change attributes classfchmodat2(), introduced in version 6.6 is currently not in the changeattribute class of audit. Calling fchmodat2() to change a fileattribute in the same fashion than chmod() or fchmodat() will bypassaudit rules such as:-w /tmp/test -p rwa -k test_rwaThe current patch adds fchmodat2() to the change attributes class.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: 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: A vulnerability was determined in jqlang jq up to 1.6. Impacted is the function run_jq_tests of the file jq_test.c of the component JSON Parser. Executing manipulation can lead to reachable assertion. The attack requires local access. The exploit has been publicly disclosed and may be utilized. Other versions might be affected as well.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- jq < 1.6-150000.3.12.1 (version in image is 1.6-150000.3.9.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config < 0.9.8-150600.11.9.1 (version in image is 0.9.8-150600.11.6.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix memory leak in idpf_vport_rel()Free vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memoryduring a reset. Reported by kmemleak:unreferenced object 0xff450acac838a000 (size 4096): comm "kworker/u258:5", pid 7732, jiffies 4296830044 hex dump (first 32 bytes): 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ backtrace (crc 3da81902): __kmalloc_cache_noprof+0x469/0x7a0 idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf] idpf_init_task+0x1ec/0x8d0 [idpf] process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x251/0x2b0 ret_from_fork_asm+0x1a/0x30
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix kmemleak by releasing references to fault configfs itemsWhen CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blkdriver sets up fault injection support by creating the timeout_inject,requeue_inject, and init_hctx_fault_inject configfs items as childrenof the top-level nullbX configfs group.However, when the nullbX device is removed, the references taken tothese fault-config configfs items are not released. As a result,kmemleak reports a memory leak, for example:unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ecFix this by explicitly releasing the references to the fault-configconfigfs items when dropping the reference to the top-level nullbXconfigfs group.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:fou: Don't allow 0 for FOU_ATTR_IPPROTO.fou_udp_recv() has the same problem mentioned in the previouspatch.If FOU_ATTR_IPPROTO is set to 0, skb is not freed byfou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().Let's forbid 0 for FOU_ATTR_IPPROTO.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:audit: add missing syscalls to read classThe "at" variant of getxattr() and listxattr() are missing from theaudit read class. Calling getxattrat() or listxattrat() on a file toread its extended attributes will bypass audit rules such as:-w /tmp/test -p rwa -k test_rwaThe current patch adds missing syscalls to the audit read class.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Initialize netdev pointer before queue setupIn setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq().However, the pointer to this structure is stored in oct->props[i].netdevonly after the calls to netif_set_real_num_rx_queues() andnetif_set_real_num_tx_queues().If either of these functions fails, setup_nic_devices() returns an errorwithout freeing the allocated netdev. Since oct->props[i].netdev is stillNULL at this point, the cleanup function liquidio_destroy_nic_device()will fail to find and free the netdev, resulting in a memory leak.Fix this by initializing oct->props[i].netdev before calling the queuesetup functions. This ensures that the netdev is properly accessible forcleanup in case of errors.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.
Packages affected:
- 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: pkgutil.get_data() did not validate the resource argument as documented, allowing path traversals.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).
-
Description: When doing a second SMB request to the same host again, curl would wrongly usea data pointer pointing into already freed memory.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- curl < 8.14.1-150700.7.14.1 (version in image is 8.14.1-150700.7.11.1).
-
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Unknown.
Packages affected:
- sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
- libssh-config < 0.9.8-150600.11.9.1 (version in image is 0.9.8-150600.11.6.1).
-
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).
-
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
- sles-release == 15.7 (version in image is 15.7-150700.28.1).
- kernel-default > 0-0 (version in image is 6.4.0-150700.53.31.1).