Description: crun is an open source OCI Container Runtime fully written in C. In affected versions A malicious container image could trick the krun handler into escaping the root filesystem, allowing file creation or modification on the host. No special permissions are needed, only the ability for the current user to write to the target file. The problem is fixed in crun 1.20 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()The function lio_target_nacl_info_show() uses sprintf() in a loop to printdetails for every iSCSI connection in a session without checking for thebuffer length. With enough iSCSI connections it's possible to overflow thebuffer provided by configfs and corrupt the memory.This patch replaces sprintf() with sysfs_emit_at() that checks for bufferboundries.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: sme: Use STR P to clear FFR context field in streaming SVE modeThe FFR is a predicate register which can vary between 16 and 256 bitsin size depending upon the configured vector length. When saving theSVE state in streaming SVE mode, the FFR register is inaccessible andso commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simplyclears the FFR field of the in-memory context structure. Unfortunately,it achieves this using an unconditional 8-byte store and so if the SMEvector length is anything other than 64 bytes in size we will eitherfail to clear the entire field or, worse, we will corrupt memoryimmediately following the structure. This has led to intermittent kfencesplats in CI [1] and can trigger kmalloc Redzone corruption messageswhen running the 'fp-stress' kselftest: | ============================================================================= | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten | ----------------------------------------------------------------------------- | | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531 | __kmalloc+0x8c/0xcc | do_sme_acc+0x9c/0x220 | ...Replace the 8-byte store with a store of a predicate register which hasbeen zero-initialised with PFALSE, ensuring that the entire field iscleared in memory.[1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:md: raid1: fix potential OOB in raid1_remove_disk()If rddev->raid_disk is greater than mddev->raid_disks, there will bean out-of-bounds in raid1_remove_disk(). We have already foundsimilar reports as follows:1) commit d17f744e883b ("md-raid10: fix KASAN warning")2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")Fix this bug by checking whether the "number" variable isvalid.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Packages affected:
podman < 4.9.5-9.1 (version in image is 4.9.5-8.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"and then dereferences it on the next line. Two lines later, we takea mutex so I don't think this is an RCU safe region. Re-order it to dothe dereferences before queuing up the free.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().smc_clc_prfx_set() is called during connect() and not under RCUnor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()after kernel_getsockname().Note that the returned value of smc_clc_prfx_set() is not usedin the caller.While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()not to touch dst there.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Packages affected:
podman < 4.9.5-9.1 (version in image is 4.9.5-8.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.
Packages affected:
podman < 4.9.5-9.1 (version in image is 4.9.5-8.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
Packages affected:
glib2-tools > 0-0 (version in image is 2.76.2-9.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.
Packages affected:
containerd > 0-0 (version in image is 1.7.27-1.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: golang-jwt is a Go implementation of JSON Web Tokens. Starting in version 3.2.0 and prior to versions 5.2.2 and 4.5.2, the function parse.ParseUnverified splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. This issue is fixed in 5.2.2 and 4.5.2.
Packages affected:
docker > 0-0 (version in image is 28.4.0_ce-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
python311-PyJWT > 0-0 (version in image is 2.9.0-1.1).
Description: A flaw was found in Podman. In a Containerfile or Podman, data written to RUN --mount=type=bind mounts during the podman build is not discarded. This issue can lead to files created within the container appearing in the temporary build context directory on the host, leaving the created files accessible.
Packages affected:
podman > 0-0 (version in image is 4.9.5-8.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
containerd < 1.7.29-1.1 (version in image is 1.7.27-1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds writes in handle_auth_session_key()The len field originates from untrusted network packets. Boundarychecks have been added to prevent potential out-of-bounds writes whendecrypting the connection secret or processing service tickets.[ idryomov: changelog ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
Packages affected:
glib2-tools > 0-0 (version in image is 2.76.2-9.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
libpng16-16 < 1.6.43-2.1 (version in image is 1.6.43-1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: delete timer and free skb queue when unloadingFix possible crash and memory leak on driver unload by deletingTX purge timer and freeing C2H queue in 'rtw_core_deinit()',shrink critical section in the latter by freeing COEX queueout of TX report lock scope.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add validation for ring_len paramThe `ring_len` parameter provided by the virtual function (VF)is assigned directly to the hardware memory context (HMC) withoutany validation.To address this, introduce an upper boundary check for both Tx and Rxqueue lengths. The maximum number of descriptors supported by thehardware is 8k-32.Additionally, enforce alignment constraints: Tx rings must be a multipleof 8, and Rx rings must be a multiple of 32.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Prevent use-after-free during requeue-PIsyzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL);In this scenario futex_wait_requeue_pi() is able to leave without usingfutex_q::lock_ptr for synchronization.This can be prevented by reading futex_q::task before updating thefutex_q::requeue_state. A reference on the task_struct is not neededbecause requeue_pi_wake_futex() is invoked with a spinlock_t held whichimplies a RCU read section.Even if T1 terminates immediately after, the task_struct will remain validduring T2's wake_up_state(). A READ_ONCE on futex_q::task beforefutex_requeue_pi_complete() is enough because it ensures that the variableis read before the state is updated.Read futex_q::task before updating the requeue state, use it for thefollowing wakeup.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix possible UAFsThis attemps to fix possible UAFs caused by struct mgmt_pending beingfreed while still being processed like in the following trace, in orderto fix mgmt_pending_valid is introduce and use to check if themgmt_pending hasn't been removed from the pending list, on the completecallbacks it is used to check and in addtion remove the cmd from the listwhile holding mgmt_pending_lock to avoid TOCTOU problems since if the cmdis left on the list it can still be accessed and freed.BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci0 hci_cmd_sync_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf---truncated---
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: Defer ip_vs_ftp unregister during netns cleanupOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftpbefore connections with valid cp->app pointers are flushed, leading to ause-after-free.Fix this by introducing a global `exiting_module` flag, set to true inip_vs_ftp_exit() before unregistering the pernet subsystem. In__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netnscleanup (when exiting_module is false) and defer it to__ip_vs_cleanup_batch(), which unregisters all apps after all connectionsare flushed. If called during module exit, unregister ip_vs_ftpimmediately.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit's also checked for decryption and in-place encryption.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Harden userspace-supplied xdp_desc validationTurned out certain clearly invalid values passed in xdp_desc fromuserspace can pass xp_{,un}aligned_validate_desc() and then leadto UBs or just invalid frames to be queued for xmit.desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_lencan cause positive integer overflow and wraparound, the same way lowenough desc->addr with a non-zero pool->tx_metadata_len can causenegative integer overflow. Both scenarios can then pass thevalidation successfully.This doesn't happen with valid XSk applications, but can be usedto perform attacks.Always promote desc->len to ``u64`` first to exclude positiveoverflows of it. Use explicit check_{add,sub}_overflow() whenvalidating desc->addr (which is ``u64`` already).bloat-o-meter reports a little growth of the code size:add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)Function old new deltaxskq_cons_peek_desc 299 330 +31xsk_tx_peek_release_desc_batch 973 1002 +29xsk_generic_xmit 3148 3132 -16but hopefully this doesn't hurt the performance much.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tls: wait for pending async decryptions if tls_strp_msg_hold failsAsync decryption calls tls_strp_msg_hold to create a clone of theinput skb to hold references to the memory it uses. If we fail toallocate that clone, proceeding with async decryption can lead tovarious issues (UAF on the skb, writing into userspace memory afterthe recv() call has returned).In this case, wait for all pending decryption requests.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race condition in mptcp_schedule_work()syzbot reported use-after-free in mptcp_schedule_work() [1]Issue here is that mptcp_schedule_work() schedules a work,then gets a refcount on sk->sk_refcnt if the work was scheduled.This refcount will be released by mptcp_worker().[A] if (schedule_work(...)) {[B] sock_hold(sk); return true; }Problem is that mptcp_worker() can run immediately and complete before [B]We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk);[1]refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix use-after-free due to MST port state bypasssyzbot reported[1] a use-after-free when deleting an expired fdb. It isdue to a race condition between learning still happening and a port beingdeleted, after all its fdbs have been flushed. The port's state has beentoggled to disabled so no learning should happen at that time, but if wehave MST enabled, it will bypass the port's state, that together with VLANfiltering disabled can lead to fdb learning at a time when it shouldn'thappen while the port is being deleted. VLAN filtering must be disabledbecause we flush the port VLANs when it's being deleted which will stoplearning. This fix adds a check for the port's vlan group which isinitialized to NULL when the port is getting deleted, that avoids the portstate bypass. When MST is enabled there would be a minimal new overheadin the fast-path because the port's vlan group pointer is cache-hot.[1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
libpng16-16 < 1.6.43-2.1 (version in image is 1.6.43-1.1).
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
libpng16-16 < 1.6.43-2.1 (version in image is 1.6.43-1.1).
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
libpng16-16 < 1.6.43-2.1 (version in image is 1.6.43-1.1).
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
libpng16-16 < 1.6.43-2.1 (version in image is 1.6.43-1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: Avoid nf_ct_helper_hash uses after freeIf nf_conntrack_init_start() fails (for example due to aregister_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()clean-up path frees the nf_ct_helper_hash map.When built with NF_CONNTRACK=y, further netfilter modules (e.g:netfilter_conntrack_ftp) can still be loaded and callnf_conntrack_helpers_register(), independently of whether nf_conntrackinitialized correctly. This accesses the nf_ct_helper_hash danglingpointer and causes a uaf, possibly leading to random memory corruption.This patch guards nf_conntrack_helper_register() from accessing a freedor uninitialized nf_ct_helper_hash pointer and fixes possibleuses-after-free when loading a conntrack module.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmountsyzbot found an invalid-free in diUnmount:BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674Free of addr ffff88806f410000 by task syz-executor131/3632 CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super.c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1186 task_work_run+0x243/0x300 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x664/0x2070 kernel/exit.c:820 do_group_exit+0x1fd/0x2b0 kernel/exit.c:950 __do_sys_exit_group kernel/exit.c:961 [inline] __se_sys_exit_group kernel/exit.c:959 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd[...]JFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount.If jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount().JFS_IP(ipimap)->i_imap will be freed once again.Fix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.alCheck pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF inproc_get_inode()"). Followed by AI Viro's suggestion, fix it in samemanner.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: avoid buffer overflow in WID string configurationFix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)This patch introduces size check before accessing the memory buffer.The checks are base on the WID type of received data from the firmware.For WID string configuration, the size limit is determined by individualelement size in 'struct wilc_cfg_str_vals' that is maintained in 'len' fieldof 'struct wilc_cfg_str'.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: xfrm_alloc_spi shouldn't use 0 as SPIx->id.spi == 0 means "no SPI assigned", but since commit94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create statesand add them to the byspi list with this value.__xfrm_state_delete doesn't remove those states from the byspi list,since they shouldn't be there, and this shows up as a UAF the nexttime we go through the byspi list.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: The CNI portmap plugin allows containers to emulate opening a host port, forwarding that traffic to the container. Versions 1.6.0 through 1.8.0 inadvertently forward all traffic with the same destination port as the host port when the portmap plugin is configured with the nftables backend, thus ignoring the destination IP. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node. Containers that request HostPort forwarding can intercept all traffic destined for that port. This requires that the portmap plugin be explicitly configured to use the nftables backend. This issue is fixed in version 1.9.0. To workaround, configure the portmap plugin to use the iptables backend. It does not have this vulnerability.
Packages affected:
docker > 0-0 (version in image is 28.4.0_ce-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: wavefront: Fix integer overflow in sample size validationThe wavefront_send_sample() function has an integer overflow issuewhen validating sample size. The header->size field is u32 but getscast to int for comparison with dev->freememFix by using unsigned comparison to avoid integer overflow.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.
Packages affected:
glibc > 0-0 (version in image is 2.38-9.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: Use of Insufficiently Random Values vulnerability in form-data allows HTTP Parameter Pollution (HPP). This vulnerability is associated with program files lib/form_data.Js.This issue affects form-data: < 2.5.4, 3.0.0 - 3.0.3, 4.0.0 - 4.0.3.
Packages affected:
cockpit-bridge > 0-0 (version in image is 309-7.2).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix incomplete state save in rxe_requesterIf a send packet is dropped by the IP layer in rxe_requester()the call to rxe_xmit_packet() can fail with err == -EAGAIN.To recover, the state of the wqe is restored to the state beforethe packet was sent so it can be resent. However, the routinesthat save and restore the state miss a significnt part of thevariable state in the wqe, the dma struct which is used to processthrough the sge table. And, the state is not saved before the packetis built which modifies the dma struct.Under heavy stress testing with many QPs on a fast node sendinglarge messages to a slow node dropped packets are observed andthe resent packets are corrupted because the dma struct was notrestored. This patch fixes this behavior and allows the test casesto succeed.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: reject auth/assoc to AP with our addressIf the AP uses our own address as its MLD address or BSSID, thenclearly something's wrong. Reject such connections so we don'ttry and fail later.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: qmi_encdec: Restrict string length in decodeThe QMI TLV value for strings in a lot of qmi element info structuresaccount for null terminated strings with MAX_LEN + 1. If a string isactually MAX_LEN + 1 length, this will cause an out of bounds accesswhen the NULL character is appended in decoding.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
Packages affected:
python311 > 0-0 (version in image is 3.11.13-2.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.
Packages affected:
glib2-tools > 0-0 (version in image is 2.76.2-9.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g.
Packages affected:
podman > 0-0 (version in image is 4.9.5-8.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: remove write-after-free of client_idA use-after-free error popped up in stress testing:[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core][Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):[Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core][Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core][Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70[Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180[Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80[Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0[Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80The actual device uninit usually happens on a separate threadscheduled after this code runs, but there is no guarantee of orderof thread execution, so this could be a problem. There's noactual need to clear the client_id at this point, so simplyremove the offending code.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cnic: Fix use-after-free bugs in cnic_delete_taskThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),which does not guarantee that the delayed work item 'delete_task' hasfully completed if it was already running. Additionally, the delayed workitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() onlyblocks and waits for work items that were already queued to theworkqueue prior to its invocation. Any work items submitted afterflush_workqueue() is called are not included in the set of tasks that theflush operation awaits. This means that after the cyclic work items havefinished executing, a delayed work item may still exist in the workqueue.This leads to use-after-free scenarios where the cnic_dev is deallocatedby cnic_free_dev(), while delete_task remains active and attempt todereference cnic_dev in cnic_delete_task().A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //useReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the cyclic delayed work item is properly canceled and that anyongoing execution of the work item completes before the cnic_dev isdeallocated. Furthermore, since cancel_delayed_work_sync() uses__flush_work(work, true) to synchronously wait for any currentlyexecuting instance of the work item to finish, the flush_workqueue()becomes redundant and should be removed.This bug was identified through static analysis. To reproduce the issueand validate the fix, I simulated the cnic PCI device in QEMU andintroduced intentional delays - such as inserting calls to ssleep()within the cnic_delete_task() function - to increase the likelihoodof triggering the bug.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver just ignores and leaves as is, which may lead tounepxected results like OOB access.This patch adds the sanity check and corrects the input mapping to thecertain default value if an invalid value is passed.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver only shows an error message but leaves as is.This may lead to unepxected results like OOB access.This patch corrects the input mapping to the certain default value ifan invalid value is passed.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix potential corruption when moving a directoryF2FS has the same issue in ext4_rename causing crash revealed byxfstests/generic/707.See also commit 0813299c586b ("ext4: Fix possible corruption when moving a directory")
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: fix race condition in unaccepted memory handlingThe page allocator tracks the number of zones that have unaccepted memoryusing static_branch_enc/dec() and uses that static branch in hot paths todetermine if it needs to deal with unaccepted memory.Borislav and Thomas pointed out that the tracking is racy: operations onstatic_branch are not serialized against adding/removing unaccepted pagesto/from the zone.Sanity checks inside static_branch machinery detects it:WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */The effect of this static_branch optimization is only visible onmicrobenchmark.Instead of adding more complexity around it, remove it altogether.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: nci: Add parameter validation for packet dataSyzbot reported an uninitialized value bug in nci_init_req, which wasintroduced by commit 5aca7966d2a7 ("Merge tag'perf-tools-fixes-for-v6.17-2025-09-16' ofgit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").This bug arises due to very limited and poor input validationthat was done at nic_valid_size(). This validation onlyvalidates the skb->len (directly reflects size provided at theuserspace interface) with the length provided in the bufferitself (interpreted as NCI_HEADER). This leads to the processingof memory content at the address assuming the correct layoutper what opcode requires there. This leads to the accesses tobuffer of `skb_buff->data` which is not assigned anything yet.Following the same silent drop of packets of invalid sizes at`nic_valid_size()`, add validation of the data in the respectivehandlers and return error values in case of failure. Releasethe skb if error values are returned from handlers in`nci_nft_packet` and effectively do a silent dropPossible TODO: because we silently drop the packets, thecall to `nci_request` will be waiting for completion of requestand will face timeouts. These timeouts can get excessively loggedin the dmesg. A proper handling of them may require to export`nci_request_cancel` (or propagate error handling from thenft packets handlers).
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs: udf: fix OOB read in lengthAllocDescs handlingWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes fromon-disk data and must be validated against the block size. Crafted orcorrupted images may set lengthAllocDescs so that the total descriptorlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory andtrigger a KASAN use-after-free read.BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:riscv: stacktrace: Disable KASAN checks for non-current tasksUnwinding the stack of a task other than current, KASAN would report"BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"There is a same issue on x86 and has been resolved by the commit84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks")The solution could be applied to RISC-V too.This patch also can solve the issue:https://seclists.org/oss-sec/2025/q4/23[pjw@kernel.org: clean up checkpatch issues]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()Use RCU to avoid a pair of atomic operations and a potentialUAF on dst_dev()->flags.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingThe Supported Rates IE length from an incoming Association Request framewas used directly as the memcpy() length when copying into a fixed-size16-byte stack buffer (supportRate). A malicious station can advertise anIE length larger than 16 bytes, causing a stack buffer overflow.Clamp ie_len to the buffer size before copying the Supported Rates IE,and correct the bounds check when merging Extended Supported Rates toprevent a second potential overflow.This prevents kernel stack corruption triggered by malformed associationrequests.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob writeWhen the oob buffer length is not in multiple of words, the oob writefunction does out-of-bounds read on the oob source buffer at the lastiteration. Fix that by always checking length limit on the oob bufferread and fill with 0xff when reaching the end of the buffer to the oobregisters.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix potential array out of bounds accessAccount for IWL_SEC_WEP_KEY_OFFSET when needed while verifyingkey_len size in iwl_mvm_sec_key_add().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:md: don't dereference mddev after export_rdev()Except for initial reference, mddev->kobject is referenced byrdev->kobject, and if the last rdev is freed, there is no guarantee thatmddev is still valid. Hence mddev should not be used anymore afterexport_rdev().This problem can be triggered by following test for mdadm at verylow rate:New file: mdadm/tests/23rdev-lifetimedevname=${dev0##*/}devt=`cat /sys/block/$devname/dev`pid=""runtime=2clean_up_test() { pill -9 $pid echo clear > /sys/block/md0/md/array_state}trap 'clean_up_test' EXITadd_by_sysfs() { while true; do echo $devt > /sys/block/md0/md/new_dev done}remove_by_sysfs(){ while true; do echo remove > /sys/block/md0/md/dev-${devname}/state done}echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"add_by_sysfs &pid="$pid $!"remove_by_sysfs &pid="$pid $!"sleep $runtimeexit 0Test cmd:./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetimeTest result:general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMPCPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]Call Trace: mddev_unlock+0x1b6/0x310 [md_mod] rdev_attr_store+0xec/0x190 [md_mod] sysfs_kf_write+0x52/0x70 kernfs_fop_write_iter+0x19a/0x2a0 vfs_write+0x3b5/0x770 ksys_write+0x74/0x150 __x64_sys_write+0x22/0x30 do_syscall_64+0x40/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdFix this problem by don't dereference mddev after export_rdev().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.
Packages affected:
libblkid1 > 0-0 (version in image is 2.39.3-3.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in i40e_validate_queue_mapEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_validate_queue_map().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: peak_usb: fix shift-out-of-bounds issueExplicitly uses a 64-bit constant when the number of bits used for itsshifting is 32 (which is the case for PC CAN FD interfaces supported bythis driver).[mkl: update subject, apply manually]
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Fix copy_to_iter return value checkThe return value of copy_to_iter can't be negative, check whether thecopied length is equal to the requested length instead of checking fornegative values.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer deference in try_to_register_cardIn try_to_register_card(), the return value of usb_ifnum_to_if() ispassed directly to usb_interface_claimed() without a NULL check, whichwill lead to a NULL pointer dereference when creating an invalidUSB audio device. Fix this by adding a check to ensure the interfacepointer is valid before passing it to usb_interface_claimed().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmodSince commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero whendevice is gone") UBSAN reports: UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17 index 28 is out of range for type 'pm8001_phy [16]'on rmmod when using an expander.For a direct attached device, attached_phy contains the local phy id.For a device behind an expander, attached_phy contains the remote phyid, not the local phy id.I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for adevice behind an expander, attached_phy can be much larger thanpm8001_ha->chip->n_phy (depending on the amount of phys of theexpander).E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of theports has an expander connected. The expander has 31 phys with phy ids0-30.The pm8001_ha->phy array only contains the phys of the HBA. It does notcontain the phys of the expander. Thus, it is wrong to use attached_phyto index the pm8001_ha->phy array for a device behind an expander.Thus, we can only clear phy_attached for devices that are directlyattached.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: guard against EA inode refcount underflow in xattr updatesyzkaller found a path where ext4_xattr_inode_update_ref() reads an EAinode refcount that is already <= 0 and then applies ref_change (often-1). That lets the refcount underflow and we proceed with a bogus value,triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117Make the invariant explicit: if the current refcount is non-positive,treat this as on-disk corruption, emit ext4_error_inode(), and fail theoperation with -EFSCORRUPTED instead of updating the refcount. Delete theWARN_ONCE() as negative refcounts are now impossible; keep error reportingin ext4_error_inode().This prevents the underflow and the follow-on orphan/cleanup churn.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Check instead of asserting on nested TSC scaling supportCheck for nested TSC scaling support on nested SVM VMRUN instead ofasserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIOhas diverged from KVM's default. Userspace can trigger the WARN at willby writing the MSR and then updating guest CPUID to hide the feature(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hackingKVM's state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd] Call Trace: enter_svm_guest_mode+0x114/0x560 [kvm_amd] nested_svm_vmrun+0x260/0x330 [kvm_amd] vmrun_interception+0x29/0x30 [kvm_amd] svm_invoke_exit_handler+0x35/0x100 [kvm_amd] svm_handle_exit+0xe7/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x45ca1bNote, the nested #VMEXIT path has the same flaw, but needs a differentfix and will be handled separately.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: fix received length check in big packetsSince commit 4959aebba8c0 ("virtio-net: use mtu size as buffer lengthfor big packets"), when guest gso is off, the allocated size for bigpackets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends onnegotiated MTU. The number of allocated frags for big packets is storedin vi->big_packets_num_skbfrags.Because the host announced buffer length can be malicious (e.g. the hostvhost_net driver's get_rx_bufs is modified to announce incorrectlength), we need a check in virtio_net receive path. Currently, thecheck is not adapted to the new change which can lead to NULL pagepointer dereference in the below while loop when receiving length thatis larger than the allocated one.This commit fixes the received length check corresponding to the newchange.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: account for current allocated stack depth in widen_imprecise_scalars()The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);Where prev_st is an ancestor of the queued_st in the explored statestree. This ancestor is not guaranteed to have same allocated stackdepth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loopHere, for a second 'foo' call prev_st->allocated_stack is 128,while queued_st->allocated_stack is much smaller.widen_imprecise_scalars() needs to take this into account and avoidaccessing bpf_verifier_state->frame[*]->stack out of bounds.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix improper freeing of purex itemIn qla2xxx_process_purls_iocb(), an item is allocated viaqla27xx_copy_multiple_pkt(), which internally callsqla24xx_alloc_purex_item().The qla24xx_alloc_purex_item() function may return a pre-allocated itemfrom a per-adapter pool for small allocations, instead of dynamicallyallocating memory with kzalloc().An error handling path in qla2xxx_process_purls_iocb() incorrectly useskfree() to release the item. If the item was from the pre-allocatedpool, calling kfree() on it is a bug that can lead to memory corruption.Fix this by using the correct deallocation function,qla24xx_free_purex_item(), which properly handles both dynamicallyallocated and pre-allocated items.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Duplicate SPI HandlingThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPINetlink message, which triggers the kernel function xfrm_alloc_spi().This function is expected to ensure uniqueness of the Security ParameterIndex (SPI) for inbound Security Associations (SAs). However, it canreturn success even when the requested SPI is already in use, leadingto duplicate SPIs assigned to multiple inbound SAs, differentiatedonly by their destination addresses.This behavior causes inconsistencies during SPI lookups for inbound packets.Since the lookup may return an arbitrary SA among those with the same SPI,packet processing can fail, resulting in packet drops.According to RFC 4301 section 4.4.2 , for inbound processing a unicast SAis uniquely identified by the SPI and optionally protocol.Reproducing the Issue Reliably:To consistently reproduce the problem, restrict the available SPI range incharon.conf : spi_min = 0x10000000 spi_max = 0x10000002This limits the system to only 2 usable SPI values.Next, create more than 2 Child SA. each using unique pair of src/dst address.As soon as the 3rd Child SA is initiated, it will be assigned a duplicateSPI, since the SPI pool is already exhausted.With a narrow SPI range, the issue is consistently reproducible.With a broader/default range, it becomes rare and unpredictable.Current implementation:xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.So if two SAs have the same SPI but different destination addresses, thenthey will:a. Hash into different bucketsb. Be stored in different linked lists (byspi + h)c. Not be seen in the same hlist_for_each_entry_rcu() iteration.As a result, the lookup will result in NULL and kernel allows that Duplicate SPIProposed Change:xfrm_state_lookup_spi_proto() does a truly global search - across all states,regardless of hash bucket and matches SPI and proto.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix a NULL pointer dereference in ath12k_mac_op_hw_scan()In ath12k_mac_op_hw_scan(), the return value of kzalloc() is directlyused in memcpy(), which may lead to a NULL pointer dereference onfailure of kzalloc().Fix this bug by adding a check of arg.extraie.ptr.Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: plug races between subflow fail and subflow creationWe have races similar to the one addressed by the previous patch betweensubflow failing and additional subflow creation. They are just harder totrigger.The solution is similar. Use a separate flag to track the condition'socket state prevent any additional subflow creation' protected by thefallback lock.The socket fallback makes such flag true, and also receiving or sendingan MP_FAIL option.The field 'allow_infinite_fallback' is now always touched under therelevant lock, we can drop the ONCE annotation on write.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:spi: cadence-quadspi: Implement refcount to handle unbind during busydriver support indirect read and indirect write operation withassumption no force device removal(unbind) operation. Howeverforce device removal(removal) is still available to root superuser.Unbinding driver during operation causes kernel crash. This changesensure driver able to handle such operation for indirect read andindirect write by implementing refcount to track attached devicesto the controller and gracefully wait and until attached devicesremove operation completed before proceed with removal operation.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix potential double free in drm_sched_job_add_resv_dependenciesWhen adding dependencies with drm_sched_job_add_dependency(), thatfunction consumes the fence reference both on success and failure, so inthe latter case the dma_fence_put() on the error path (xarray failed toexpand) is a double free.Interestingly this bug appears to have been present ever sincecommit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the codeback then looked like this:drm_sched_job_add_implicit_dependencies():... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]);Which means for the failing 'i' the dma_fence_put was already a doublefree. Possibly there were no users at that time, or the test cases wereinsufficient to hit it.The bug was then only noticed and fixed aftercommit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")landed, with its fixup ofcommit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").At that point it was a slightly different flavour of a double free, whichcommit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")noticed and attempted to fix.But it only moved the double free from happening inside thedrm_sched_job_add_dependency(), when releasing the reference not yetobtained, to the caller, when releasing the reference already released bythe former in the failure case.As such it is not easy to identify the right target for the fixes tag solets keep it simple and just continue the chain.While fixing we also improve the comment and explain the reason for takingthe reference and not dropping it.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject negative offsets for ALU opsWhen verifying BPF programs, the check_alu_op() function validatesinstructions with ALU operations. The 'offset' field in theseinstructions is a signed 16-bit integer.The existing check 'insn->off > 1' was intended to ensure the offset iseither 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' issigned, this check incorrectly accepts all negative values (e.g., -1).This commit tightens the validation by changing the condition to'(insn->off != 0 && insn->off != 1)'. This ensures that any valueother than the explicitly permitted 0 and 1 is rejected, hardening theverifier against malformed BPF programs.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: ipc: fix use-after-free in ipc_msg_send_requestipc_msg_send_request() waits for a generic netlink reply using anipc_msg_table_entry on the stack. The generic netlink handler(handle_generic_event()/handle_response()) fills entry->response underipc_msg_table_lock, but ipc_msg_send_request() used to validate and freeentry->response without holding the same lock.Under high concurrency this allows a race where handle_response() iscopying data into entry->response while ipc_msg_send_request() has justfreed it, leading to a slab-use-after-free reported by KASAN inhandle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]Fix by:- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table.- Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock.- Returning NULL in the error path, preserving the original API semantics.This makes all accesses to entry->response consistent withhandle_response(), which already updates and fills the response bufferunder ipc_msg_table_lock, and closes the race that allowed the UAF.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix MSDU buffer types handling in RX error pathCurrently, packets received on the REO exception ring fromunassociated peers are of MSDU buffer type, while the driver expectslink descriptor type packets. These packets are not parsed further dueto a return check on packet type in ath12k_hal_desc_reo_parse_err(),but the associated skb is not freed. This may lead to kernelcrashes and buffer leaks.Hence to fix, update the RX error handler to explicitly dropMSDU buffer type packets received on the REO exception ring.This prevents further processing of invalid packets and ensuresstability in the RX error handling path.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: make sure skb->len != 0 when redirecting to a tunneling devicesyzkaller managed to trigger another case where skb->len == 0when we enter __dev_queue_xmit:WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6The reproducer doesn't really reproduce outside of syzkallerenvironment, so I'm taking a guess here. It looks like wedo generate correct ETH_HLEN-sized packet, but we redirectthe packet to the tunneling device. Before we do so, we__skb_pull l2 header and arrive again at skb->len == 0.Doesn't seem like we can do anything better than havingan explicit check after __skb_pull?
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length checkThe vdpa_nl_policy structure is used to validate the nlattr when parsingthe incoming nlmsg. It will ensure the attribute being described producesa valid nlattr pointer in info->attrs before entering into each handlerin vdpa_nl_ops.That is to say, the missing part in vdpa_nl_policy may lead to illegalnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.This patch adds the missing nla_policy for vdpa max vqp attr to avoidsuch bugs.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctxwhen mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memorypointed by 'in' is not released, which will cause memory leak. Move memoryrelease after mlx5_cmd_exec.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: amd-pstate: fix global sysfs attribute typeIn commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")the "amd_pstate" attributes where moved from a dedicated kobject to thecpu root kobject.While the dedicated kobject expects to contain kobj_attributes the rootkobject needs device_attributes.As the changed arguments are not used by the callbacks it works most ofthe time.However CFI will detect this issue:[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)...[ 4947.849409] Call Trace:[ 4947.849410] [ 4947.849411] ? __warn+0xcf/0x1c0[ 4947.849414] ? dev_attr_show+0x24/0x60[ 4947.849415] ? report_cfi_failure+0x4e/0x60[ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0[ 4947.849419] ? __cfi_show_status+0x10/0x10[ 4947.849420] ? handle_bug+0x4f/0x90[ 4947.849421] ? exc_invalid_op+0x1a/0x60[ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20[ 4947.849424] ? __cfi_show_status+0x10/0x10[ 4947.849425] ? dev_attr_show+0x24/0x60[ 4947.849426] sysfs_kf_seq_show+0xa6/0x110[ 4947.849433] seq_read_iter+0x16c/0x4b0[ 4947.849436] vfs_read+0x272/0x2d0[ 4947.849438] ksys_read+0x72/0xe0[ 4947.849439] do_syscall_64+0x76/0xb0[ 4947.849440] ? do_user_addr_fault+0x252/0x650[ 4947.849442] ? exc_page_fault+0x7a/0x1b0[ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: mark requests for GuC virtual engines to avoid use-after-freeReferences to i915_requests may be trapped by userspace inside async_file or dmabuf (dma-resv) and held indefinitely across differentproceses. To counter-act the memory leaks, we try to not to keepreferences from the request past their completion.On the other side on fence release we need to know if rq->engineis valid and points to hw engine (true for non-virtual requests).To make it possible extra bit has been added to rq->execution_mask,for marking virtual engines.(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:HID: hyperv: avoid struct memcpy overrun warningA previous patch addressed the fortified memcpy warning for mostbuilds, but I still see this one with gcc-9:In file included from include/linux/string.h:254, from drivers/hid/hid-hyperv.c:8:In function 'fortify_memcpy_chk', inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~My guess is that the WARN_ON() itself is what confuses gcc, so it nolonger sees that there is a correct range check. Rework the code in away that helps readability and avoids the warning.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()The "exc->key_len" is a u16 that comes from the user. If it's overIW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/core: initialize damo_filter->list from damos_new_filter()damos_new_filter() is not initializing the list field of newly allocatedfilter object. However, DAMON sysfs interface and DAMON_RECLAIM are notinitializing it after calling damos_new_filter(). As a result, accessinguninitialized memory is possible. Actually, adding multiple DAMOS filtersvia DAMON sysfs interface caused NULL pointer dereferencing. Initializethe field just after the allocation from damos_new_filter().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fprobe: Release rethook after the ftrace_ops is unregisteredWhile running bpf selftests it's possible to get following fault: general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI ... Call Trace: fprobe_handler+0xc1/0x270 ? __pfx_bpf_testmod_init+0x10/0x10 ? __pfx_bpf_testmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initcall+0x63/0x2e0 ? rcu_is_watching+0xd/0x40 ? kmalloc_trace+0xaf/0xc0 ? do_init_module+0x60/0x250 ? __do_sys_finit_module+0xac/0x120 ? do_syscall_64+0x37/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc In unregister_fprobe function we can't release fp->rethook while it'spossible there are some of its users still running on another cpu.Moving rethook_free call after fp->ops is unregistered withunregister_ftrace_function call.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ip_vti: fix potential slab-use-after-free in decode_session6When ip_vti device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when ip_vti device sends IPv6 packets.As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: don't leak memory if dev_set_name() failsWhen dev_set_name() fails, zcdn_create() doesn't free the newlyallocated resources. Do it.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count thenumber of MBSSID elements in the nested netlink attribute attrs, which canlead to an integer overflow if a user of the nl80211 interface specifies256 or more elements in the corresponding attribute in userspace. Theinteger overflow can lead to a heap buffer overflow as num_elems determinesthe size of the trailing array in elems, and this array is thereafterwritten to for each element in attrs.Note that this vulnerability only affects devices with thewiphy->mbssid_max_interfaces member set for the wireless physical devicestruct in the device driver, and can only be triggered by a process withCAP_NET_ADMIN capabilities.Fix this by checking for a maximum of 255 elements in attrs.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: scu: use _safe list iterator to avoid a use after freeThis loop is freeing "clk" so it needs to use list_for_each_entry_safe().Otherwise it dereferences a freed variable to get the next item on theloop.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, cpumap: Make sure kthread is running before map update returnsThe following warning was reported when running stress-mode enabledxdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memoryleak in cpu_map_update_elem"). The kthread is stopped prematurely bykthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't callcpu_map_kthread_run() at all but XDP program has already queued someframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checksthe ptr_ring, it will find it was not emptied and report a warning.An alternative fix is to use __cpu_map_ring_cleanup() to drop thesepending frames or skbs when kthread_stop() returns -EINTR, but it mayconfuse the user, because these frames or skbs have been handledcorrectly by XDP program. So instead of dropping these frames or skbs,just make sure the per-cpu kthread is running before__cpu_map_entry_alloc() returns.After apply the fix, the error handle for kthread_stop() will beunnecessary because it will always return 0, so just remove it.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:gpio: mvebu: fix irq domain leakUwe Kleine-K?nig pointed out we still have one resource leak in the mvebudriver triggered on driver detach. Let's address it with a custom devmaction.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:USB: Gadget: core: Help prevent panic during UVC unconfigureAvichal Rakesh reported a kernel panic that occurred when the UVCgadget driver was removed from a gadget's configuration. The panicinvolves a somewhat complicated interaction between the kernel driverand a userspace component (as described in the Link tag below), butthe analysis did make one thing clear: The Gadget core shouldaccomodate gadget drivers calling usb_gadget_deactivate() as part oftheir unbind procedure.Currently this doesn't work. gadget_unbind_driver() callsdriver->unbind() while holding the udc->connect_lock mutex, andusb_gadget_deactivate() attempts to acquire that mutex, which willresult in a deadlock.The simple fix is for gadget_unbind_driver() to release the mutex wheninvoking the ->unbind() callback. There is no particular reason forit to be holding the mutex at that time, and the mutex isn't heldwhile the ->bind() callback is invoked. So we'll drop the mutexbefore performing the unbind callback and reacquire it afterward.We'll also add a couple of comments to usb_gadget_activate() andusb_gadget_deactivate(). Because they run in process context theymust not be called from a gadget driver's ->disconnect() callback,which (according to the kerneldoc for struct usb_gadget_driver ininclude/linux/usb/gadget.h) may run in interrupt context. This mayhelp prevent similar bugs from arising in the future.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Release folio lock on fscache read hit.Under the current code, when cifs_readpage_worker is called, the callcontract is that the callee should unlock the page. This is documentedin the read_folio section of Documentation/filesystems/vfs.rst as:> The filesystem should unlock the folio once the read has completed,> whether it was successful or not.Without this change, when fscache is in use and cache hit occurs duringa read, the page lock is leaked, producing the following stack onsubsequent reads (via mmap) to the page:$ cat /proc/3890/task/12864/stack[<0>] folio_wait_bit_common+0x124/0x350[<0>] filemap_read_folio+0xad/0xf0[<0>] filemap_fault+0x8b1/0xab0[<0>] __do_fault+0x39/0x150[<0>] do_fault+0x25c/0x3e0[<0>] __handle_mm_fault+0x6ca/0xc70[<0>] handle_mm_fault+0xe9/0x350[<0>] do_user_addr_fault+0x225/0x6c0[<0>] exc_page_fault+0x84/0x1b0[<0>] asm_exc_page_fault+0x27/0x30This requires a reboot to resolve; it is a deadlock.Note however that the call to cifs_readpage_from_fscache does mark thepage clean, but does not free the folio lock. This happens in__cifs_readpage_from_fscache on success. Releasing the lock at thatpoint however is not appropriate as cifs_readahead also callscifs_readpage_from_fscache and *does* unconditionally release the lockafter its return. This change therefore effectively makescifs_readpage_worker work like cifs_readahead.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drivers: base: Free devm resources when unregistering a deviceIn the current code, devres_release_all() only gets called if the devicehas a bus and has been probed.This leads to issues when using bus-less or driver-less devices wherethe device might never get freed if a managed resource holds a referenceto the device. This is happening in the DRM framework for example.We should thus call devres_release_all() in the device_del() function tomake sure that the device-managed actions are properly executed when thedevice is unregistered, even if it has neither a bus nor a driver.This is effectively the same change than commit 2f8d16a996da ("devres:release resources on device_del()") that got reverted by commita525a3ddeaca ("driver core: free devres in device_release") overmemory leaks concerns.This patch effectively combines the two commits mentioned above torelease the resources both on device_del() and device_release() and getthe best of both worlds.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix mid leak during reconnection after timeout thresholdWhen the number of responses with status of STATUS_IO_TIMEOUTexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnectthe connection. But we do not return the mid, or the creditsreturned for the mid, or reduce the number of in-flight requests.This bug could result in the server->in_flight count to go bad,and also cause a leak in the mids.This change moves the check to a few lines below where theresponse is decrypted, even of the response is read from thetransform header. This way, the code for returning the midscan be reused.Also, the cifs_reconnect was reconnecting just the transportconnection before. In case of multi-channel, this may not bewhat we want to do after several timeouts. Changed that toreconnect the session and the tree too.Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate nameMAX_STATUS_IO_TIMEOUT.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to pointto the scatterlist array in areq->first_rsgl.sgl.sgl.Without this, the gcm-aes-s390 driver will oops when it tries to dogcm_walk_start() on req->dst because req->dst is set to the value ofareq->first_rsgl.sgl.sgl by _aead_recvmsg() callingaead_request_set_crypt().The problem comes if an empty ciphertext is passed: the loop inaf_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsglup.This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as faras I can tell, that ignores req->dst and only uses req->src[*].[*] Is this a bug in aesni-intel_glue.c?The s390x oops looks something like: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000a00000000 TEID: 0000000a00000803 Fault in home space mode while using kernel ASCE. AS:00000000a43a0007 R3:0000000000000024 Oops: 003b ilc:2 [#1] SMP ... Call Trace: [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390] [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8 [<00000000a2a60888>] aead_recvmsg+0x478/0x698 [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0 [<00000000a2e51a56>] sock_read_iter+0x76/0xa0 [<00000000a273e066>] vfs_read+0x26e/0x2a8 [<00000000a273e8c4>] ksys_read+0xbc/0x100 [<00000000a311d808>] __do_syscall+0x1d0/0x1f8 [<00000000a312ff30>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390]
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tunnels: fix kasan splat when generating ipv4 pmtu errorIf we try to emit an icmp error in response to a nonliner skb, we getBUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220Read of size 4 at addr ffff88811c50db00 by task iperf3/1691CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309[..] kasan_report+0x105/0x140 ip_compute_csum+0x134/0x220 iptunnel_pmtud_build_icmp+0x554/0x1020 skb_tunnel_check_pmtu+0x513/0xb80 vxlan_xmit_one+0x139e/0x2ef0 vxlan_xmit+0x1867/0x2760 dev_hard_start_xmit+0x1ee/0x4f0 br_dev_queue_push_xmit+0x4d1/0x660 [..]ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.After this change, splat is gone and iperf3 is no longer stuck.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Avoid fcport pointer dereferenceKlocwork reported warning of NULL pointer may be dereferenced. The routineexits when sa_ctl is NULL and fcport is allocated after the exit call thuscausing NULL fcport pointer to dereference at the time of exit.To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi_si: fix a memleak in try_smi_init()Kmemleak reported the following leak info in try_smi_init():unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180The problem was that when an error occurred before handlers registrationand after allocating `new_smi->si_sm`, the variable wouldn't be freed inthe error handling afterwards since `shutdown_smi()` hadn't beenregistered yet. Fix it by adding a `kfree()` in the error handling pathin `try_smi_init()`.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:dax: Fix dax_mapping_release() use after freeA CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax regionprovider (like modprobe -r dax_hmem) yields: kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000) [..] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: [..] lock_acquire+0xd4/0x2c0 ? ida_free+0x62/0x130 _raw_spin_lock_irqsave+0x47/0x70 ? ida_free+0x62/0x130 ida_free+0x62/0x130 dax_mapping_release+0x1f/0x30 device_release+0x36/0x90 kobject_delayed_cleanup+0x46/0x150Due to attempting ida_free() on an ida object that has already beenfreed. Devices typically only hold a reference on their parent whileregistered. If a child needs a parent object to complete its release itneeds to hold a reference that it drops from its release callback.Arrange for a dax_mapping to pin its parent dev_dax instance untildax_mapping_release().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix deletion race conditionSystem crash when using debug kernel due to link list corruption. The causeof the link list corruption is due to session deletion was allowed to queueup twice. Here's the internal trace that show the same port was allowed todouble queue for deletion on different cpu.20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 120808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1Move the clearing/setting of deleted flag lock.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: socinfo: Add kfree for kstrdupAdd kfree() in the later error handling in order to avoid memory leak.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject invalid reloc tree root keys with stack dump[BUG]Syzbot reported a crash that an ASSERT() got triggered insideprepare_to_merge().That ASSERT() makes sure the reloc tree is properly pointed back by itssubvolume tree.[CAUSE]After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.But reloc trees can only exist for subvolumes, as for non-subvolumetrees, we just COW the involved tree block, no need to create a reloctree since those tree blocks won't be shared with other trees.Only subvolumes tree can share tree blocks with other trees (thus theyhave BTRFS_ROOT_SHAREABLE flag).Thus this new debug output proves my previous assumption that corruptedon-disk data can trigger that ASSERT().[FIX]Besides the dedicated fix and the graceful exit, also let tree-checker tocheck such root keys, to make sure reloc trees can only exist for subvolumes.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-sysman: Fix reference leakIf a duplicate attribute is found using kset_find_obj(),a reference to that attribute is returned. This meansthat we need to dispose it accordingly. Use kobject_put()to dispose the duplicate attribute in such a case.Compile-tested only.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: cancel queued works in probe error pathIf it fails to get the devices's MAC address, octep_probe exits whileleaving the delayed work intr_poll_task queued. When the work laterruns, it's a use after free.Move the cancelation of intr_poll_task from octep_remove intooctep_device_cleanup. This does not change anything in the octep_removeflow, but octep_device_cleanup is called also in the octep_probe errorpath, where the cancelation is needed.Note that the cancelation of ctrl_mbox_task has to followintr_poll_task's, because the ctrl_mbox_task may be queued byintr_poll_task.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make bpf_refcount_acquire fallible for non-owning refsThis patch fixes an incorrect assumption made in the originalbpf_refcount series [0], specifically that the BPF program callingbpf_refcount_acquire on some node can always guarantee that the node isalive. In that series, the patch adding failure behavior to rbtree_addand list_push_{front, back} breaks this assumption for non-owningreferences.Consider the following program: n = bpf_kptr_xchg(&mapval, NULL); /* skip error checking */ bpf_spin_lock(&l); if(bpf_rbtree_add(&t, &n->rb, less)) { bpf_refcount_acquire(n); /* Failed to add, do something else with the node */ } bpf_spin_unlock(&l);It's incorrect to assume that bpf_refcount_acquire will always succeed in thisscenario. bpf_refcount_acquire is being called in a critical sectionhere, but the lock being held is associated with rbtree t, which isn'tnecessarily the lock associated with the tree that the node is alreadyin. So after bpf_rbtree_add fails to add the node and calls bpf_obj_dropin it, the program has no ownership of the node's lifetime. Thereforethe node's refcount can be decr'd to 0 at any time after the failingrbtree_add. If this happens before the refcount_acquire above, the nodemight be free'd, and regardless refcount_acquire will be incrementing a0 refcount.Later patches in the series exercise this scenario, resulting in theexpected complaint from the kernel (without this patch's changes): refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110 Modules linked in: bpf_testmod(O) CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0xbc/0x110 Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff <0f> 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7 RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680 RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7 R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388 R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048 FS: 00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: bpf_refcount_acquire_impl+0xb5/0xc0 (rest of output snipped)The patch addresses this by changing bpf_refcount_acquire_impl to userefcount_inc_not_zero instead of refcount_inc and markingbpf_refcount_acquire KF_RET_NULL.For owning references, though, we know the above scenario is not possibleand thus that bpf_refcount_acquire will always succeed. Some verifierbookkeeping is added to track "is input owning ref?" for bpf_refcount_acquirecalls and return false from is_kfunc_ret_null for bpf_refcount_acquire onowning refs despite it being marked KF_RET_NULL.Existing selftests using bpf_refcount_acquire are modified wherenecessary to NULL-check its return value. [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/perf: add sentinel to xehp_oa_b_countersArrays passed to reg_in_range_table should end with empty record.The patch solves KASAN detected bug with signature:BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]Read of size 4 at addr ffffffffa1555d90 by task perf/1518CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023Call Trace:...xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915](cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't dereference ACPI root object handleSince the commit referenced in the Fixes: tag below the VMBus client driveris walking the ACPI namespace up from the VMBus ACPI device to the ACPInamespace root object trying to find Hyper-V MMIO ranges.However, if it is not able to find them it ends trying to walk resources ofthe ACPI namespace root object itself.This object has all-ones handle, which causes a NULL pointer dereferencein the ACPI code (from dereferencing this pointer with an offset).This in turn causes an oops on boot with VMBus host implementations that donot provide Hyper-V MMIO ranges in their VMBus ACPI device or itsancestors.The QEMU VMBus implementation is an example of such implementation.I guess providing these ranges is optional, since all tested Windowsversions seem to be able to use VMBus devices without them.Fix this by explicitly terminating the lookup at the ACPI namespace rootobject.Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interfaceby default - they only do so if the KVM PV interface is missing ordisabled.Example stack trace of such oops:[ 3.710827] ? __die+0x1f/0x60[ 3.715030] ? page_fault_oops+0x159/0x460[ 3.716008] ? exc_page_fault+0x73/0x170[ 3.716959] ? asm_exc_page_fault+0x22/0x30[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0[ 3.723559] ? down_timeout+0x3a/0x60[ 3.724455] ? acpi_ns_get_node+0x3a/0x60[ 3.725412] acpi_ns_get_node+0x3a/0x60[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0[ 3.728400] acpi_rs_get_method_data+0x2b/0x70[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.732411] acpi_walk_resources+0x78/0xd0[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus][ 3.734802] platform_probe+0x3d/0x90[ 3.735684] really_probe+0x19b/0x400[ 3.736570] ? __device_attach_driver+0x100/0x100[ 3.737697] __driver_probe_device+0x78/0x160[ 3.738746] driver_probe_device+0x1f/0x90[ 3.739743] __driver_attach+0xc2/0x1b0[ 3.740671] bus_for_each_dev+0x70/0xc0[ 3.741601] bus_add_driver+0x10e/0x210[ 3.742527] driver_register+0x55/0xf0[ 3.744412] ? 0xffffffffc039a000[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixersmatch error:sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:we previously assumed 'rac97' could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add features attr to vdpa_nl_policy for nlattr length checkThe vdpa_nl_policy structure is used to validate the nlattr when parsingthe incoming nlmsg. It will ensure the attribute being described producesa valid nlattr pointer in info->attrs before entering into each handlerin vdpa_nl_ops.That is to say, the missing part in vdpa_nl_policy may lead to illegalnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.This patch adds the missing nla_policy for vdpa features attr to avoidsuch bugs.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:media: amphion: fix REVERSE_INULL issues reported by coveritynull-checking of a pointor is suggested before dereferencing it
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't tx before switchdev is fully configuredThere is possibility that ice_eswitch_port_start_xmit might becalled while some resources are still not allocated which mightcause NULL pointer dereference. Fix this by checking if switchdevconfiguration was finished.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:spi: bcm-qspi: return error if neither hif_mspi nor mspi is availableIf neither a "hif_mspi" nor "mspi" resource is present, the driver willjust early exit in probe but still return success. Apart from not doinganything meaningful, this would then also lead to a null pointer accesson removal, as platform_get_drvdata() would return NULL, which it wouldthen try to dereference when trying to unregister the spi master.Fix this by unconditionally calling devm_ioremap_resource(), as it canhandle a NULL res and will then return a viable ERR_PTR() if we get one.The "return 0;" was previously a "goto qspi_resource_err;" where thenret was returned, but since ret was still initialized to 0 at this placethis was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fixuse-after-free on unbind"). The issue was not introduced by this commit,only made more obvious.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, cpumap: Handle skb as well when clean up ptr_ringThe following warning was reported when running xdp_redirect_cpu withboth skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150 __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 The reason for the warning is twofold. One is due to the kthreadcpu_map_kthread_run() is stopped prematurely. Another one is__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs inptr_ring as XDP frames.Prematurely-stopped kthread will be fixed by the preceding patch andptr_ring will be empty when __cpu_map_ring_cleanup() is called. Butas the comments in __cpu_map_ring_cleanup() said, handling and freeingskbs in ptr_ring as well to "catch any broken behaviour gracefully".
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd938x: fix missing mbhc init error handlingMBHC initialisation can fail so add the missing error handling to avoiddereferencing an error pointer when later configuring the jack: Unable to handle kernel paging request at virtual address fffffffffffffff8 pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc] lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x] Call trace: wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc] wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x] snd_soc_component_set_jack+0x28/0x8c [snd_soc_core] qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common] sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp] snd_soc_link_init+0x28/0x90 [snd_soc_core] snd_soc_bind_card+0x628/0xbfc [snd_soc_core] snd_soc_register_card+0xec/0x104 [snd_soc_core] devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core] sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: Fix the memory leak in raw_gadget driverCurrently, increasing raw_dev->count happens before invoke theraw_queue_event(), if the raw_queue_event() return error, invokeraw_release() will not trigger the dev_free() to be called.[ 268.905865][ T5067] raw-gadget.0 gadget.0: failed to queue event[ 268.912053][ T5067] udc dummy_udc.0: failed to start USB Raw Gadget: -12[ 268.918885][ T5067] raw-gadget.0: probe of gadget.0 failed with error -12[ 268.925956][ T5067] UDC core: USB Raw Gadget: couldn't find an available UDC or it's busy[ 268.934657][ T5067] misc raw-gadget: fail, usb_gadget_register_driver returned -16BUG: memory leak[] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] kzalloc include/linux/slab.h:703 [inline][] dev_new drivers/usb/gadget/legacy/raw_gadget.c:191 [inline][] raw_open+0x45/0x110 drivers/usb/gadget/legacy/raw_gadget.c:385[] misc_open+0x1a9/0x1f0 drivers/char/misc.c:165[] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] raw_ioctl_init+0xdf/0x410 drivers/usb/gadget/legacy/raw_gadget.c:460[] raw_ioctl+0x5f9/0x1120 drivers/usb/gadget/legacy/raw_gadget.c:1250[] vfs_ioctl fs/ioctl.c:51 [inline][] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] kzalloc include/linux/slab.h:703 [inline][] dummy_alloc_request+0x5a/0xe0 drivers/usb/gadget/udc/dummy_hcd.c:665[] usb_ep_alloc_request+0x22/0xd0 drivers/usb/gadget/udc/core.c:196[] gadget_bind+0x6d/0x370 drivers/usb/gadget/legacy/raw_gadget.c:292This commit therefore invoke kref_get() under the condition thatraw_queue_event() return success.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1The type of size is unsigned int, if size is 0x40000000, there willbe an integer overflow, size will be zero after size *= sizeof(uint32_t),will cause uninitialized memory to be referenced later.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: avoid stalls in fq_pie_timer()When setting a high number of flows (limit being 65536),fq_pie_timer() is currently using too much time as syzbot reported.Add logic to yield the cpu every 2048 flows (less than 150 usecon debug kernels).It should also help by not blocking qdisc fast paths for too long.Worst case (65536 flows) would need 31 jiffies for a complete scan.Relevant extract from syzbot report:rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.rcu: blocking rcu_node structures (internal RCU debug):Sending NMI from CPU 1 to CPUs 0:NMI backtrace for cpu 0CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8bRSP: 0018:ffffc90000007bb8 EFLAGS: 00000206RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/hyperv: Disable IBT when hypercall page lacks ENDBR instructionOn hardware that supports Indirect Branch Tracking (IBT), Hyper-V VMswith ConfigVersion 9.3 or later support IBT in the guest. However,current versions of Hyper-V have a bug in that there's not an ENDBR64instruction at the beginning of the hypercall page. Since hypercalls aremade with an indirect call to the hypercall page, all hypercall attemptsfail with an exception and Linux panics.A Hyper-V fix is in progress to add ENDBR64. But guard against the Linuxpanic by clearing X86_FEATURE_IBT if the hypercall page doesn't startwith ENDBR. The VM will boot and run without IBT.If future Linux 32-bit kernels were to support IBT, additional hypercallpage hackery would be needed to make IBT work for such kernels in aHyper-V VM.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Disable works on hci_unregister_devThis make use of disable_work_* on hci_unregister_dev since the hci_dev isabout to be freed new submissions are not disarable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Disable iocc if dma-coherent property isn't setIf dma-coherent property isn't set then descriptors are non-cacheableand the iocc shareability bits should be disabled. Without this UFS canend up in an incompatible configuration and suffer from random cacherelated stability issues.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Fix in_atomic() handling in do_secure_storage_access()Kernel user spaces accesses to not exported pages in atomic contextincorrectly try to resolve the page fault.With debug options enabled call traces like this can be seen:BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39preempt_count: 1, expected: 0RCU nest depth: 0, expected: 0INFO: lockdep is turned off.Preemption disabled at:[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPTTainted: [W]=WARNHardware name: IBM 3931 A01 703 (LPAR)Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90INFO: lockdep is turned off.It is not allowed to take the mmap_lock while in atomic context. Thereforehandle such a secure storage access fault as if the accessed page is notmapped: the uaccess function will return -EFAULT, and the caller has todeal with this. Usually this means that the access is retried in processcontext, which allows to resolve the page fault (or in this case export thepage).
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Prevent ALIGN() overflowWhen allocating IOVA the candidate range gets aligned to the targetalignment. If the range is close to ULONG_MAX then the ALIGN() canwrap resulting in a corrupted iova.Open code the ALIGN() using get_add_overflow() to prevent this.This simplifies the checks as we don't need to check for length earliereither.Consolidate the two copies of this code under a single helper.This bug would allow userspace to create a mapping that overlaps with someother mapping or a reserved range.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Fix jump offset calculation in tailcallThe extra pass of bpf_int_jit_compile() skips JIT context initializationwhich essentially skips offset calculation leaving out_offset = -1, sothe jmp_offset in emit_bpf_tail_call is calculated by"#define jmp_offset (out_offset - (cur_offset))"is a negative number, which is wrong. The final generated assembly areas follow.54: bgeu $a2, $t1, -8 # 0x0000004c58: addi.d $a6, $s5, -15c: bltz $a6, -16 # 0x0000004c60: alsl.d $t2, $a2, $a1, 0x364: ld.d $t2, $t2, 26468: beq $t2, $zero, -28 # 0x0000004cBefore apply this patch, the follow test case will reveal soft lock issues.cd tools/testing/selftests/bpf/./test_progs --allow=tailcalls/tailcall_bpf2bpf_1dmesg:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix race conditions in ppp_fill_forward_pathppp_fill_forward_path() has two race conditions:1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic.2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.Fix these by using a lockless RCU approach:- Use list_first_or_null_rcu() to safely test and access the first list entry.- Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal.- Check for a NULL pch->chan before dereferencing it.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a race when updating an existing writeAfter nfs_lock_and_join_requests() tests for whether the request isstill attached to the mapping, nothing prevents a call tonfs_inode_remove_request() from succeeding until we actually lock thepage group.The reason is that whoever called nfs_inode_remove_request() doesn'tnecessarily have a lock on the page group head.So in order to avoid races, let's take the page group lock earlier innfs_lock_and_join_requests(), and hold it across the removal of therequest in nfs_inode_remove_request().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: Optimize module load time by optimizing PLT/GOT countingWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD andCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,the relevant logs are as follows:rcu: INFO: rcu_sched self-detected stall on CPU...Call Trace:[<900000000024f9e4>] show_stack+0x5c/0x180[<90000000002482f4>] dump_stack_lvl+0x94/0xbc[<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280[<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88[<9000000000396c34>] update_process_times+0xb4/0x150[<90000000003b2474>] tick_nohz_handler+0xf4/0x250[<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428[<9000000000399b2c>] hrtimer_interrupt+0x214/0x538[<9000000000253634>] constant_timer_interrupt+0x64/0x80[<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0[<9000000000349a78>] handle_irq_event_percpu+0x18/0x88[<9000000000354c00>] handle_percpu_irq+0x90/0xf0[<9000000000348c74>] handle_irq_desc+0x94/0xb8[<9000000001012b28>] handle_cpu_irq+0x68/0xa0[<9000000001def8c0>] handle_loongarch_irq+0x30/0x48[<9000000001def958>] do_vint+0x80/0xd0[<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0[<90000000006344f4>] __asan_load8+0x4c/0x120[<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8[<90000000003895f0>] load_module+0x9e0/0x2958[<900000000038b770>] __do_sys_init_module+0x208/0x2d0[<9000000001df0c34>] do_syscall+0x94/0x190[<900000000024d6fc>] handle_syscall+0xbc/0x158After analysis, this is because the slow speed of loading the amdgpumodule leads to the long time occupation of the cpu and then the softdeadlock.When loading a module, module_frob_arch_sections() tries to figure outthe number of PLTs/GOTs that will be needed to handle all the RELAs. Itwill call the count_max_entries() to find in an out-of-order date whichcounting algorithm has O(n^2) complexity.To make it faster, we sort the relocation list by info and addend. Thatway, to check for a duplicate relocation, it just needs to compare withthe previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize moduleload time by optimizing PLT counting"). This gives sinificant reductionin module load time for modules with large number of relocations.After applying this patch, the soft deadlock problem has been solved,and the kernel starts normally without "Call Trace".Using the default configuration to test some modules, the results are asfollows:Module Sizeip_tables 36Kfat 143Kradeon 2.5MBamdgpu 16MBWithout this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 54 1221/84amdgpu 1411 4525/1098With this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 22 1221/84amdgpu 45 4525/1098
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let's call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won't see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ARM: tegra: Use I/O memcpy to write to IRAMKasan crashes the kernel trying to check boundaries when using thenormal memcpy.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix unregister_netdev call order in macb_remove()When removing a macb device, the driver calls phy_exit() beforeunregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ...The warning happens because the PHY is being exited while the netdevis still registered. The correct order is to unregister the netdevbefore shutting down the PHY and cleaning up the MDIO bus.Fix this by moving unregister_netdev() ahead of phy_exit() inmacb_remove().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD when refreshing an FDB entry with a nexthop objectVXLAN FDB entries can point to either a remote destination or an FDBnexthop group. The latter is usually used in EVPN deployments wherelearning is disabled.However, when learning is enabled, an incoming packet might try torefresh an FDB entry that points to an FDB nexthop group and thereforedoes not have a remote. Such packets should be dropped, but they areonly dropped after dereferencing the non-existent remote, resulting in aNPD [1] which can be reproduced using [2].Fix by dropping such packets earlier. Remove the misleading comment fromfirst_remote_rcu().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_snoop+0x98/0x1e0[...]Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdogThe ptp_ocp_detach() only shuts down the watchdog timer if it ispending. However, if the timer handler is already running, thetimer_delete_sync() is not called. This leads to race conditionswhere the devlink that contains the ptp_ocp is deallocated whilethe timer handler is still accessing it, resulting in use-after-freebugs. The following details one of the race scenarios.(thread 1) | (thread 2)ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //useResolve this by unconditionally calling timer_delete_sync() to ensurethe timer is reliably deactivated, preventing any access after free.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix invalid accesses to ceph_connection_v1_infoThere is a place where generic code in messenger.c is reading andanother place where it is writing to con->v1 union member withoutchecking that the union member is active (i.e. msgr1 is in use).On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,so such a read is almost guaranteed to return a bogus value instead of0 when msgr2 is in use. This ends up being fairly benign because theside effect is just the invalidation of the authorizer and successivefetching of new tickets.con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact thatit's being written to can cause more serious consequences, but luckilyit's not something that happens often.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:kernfs: Fix UAF in polling when open file is releasedA use-after-free (UAF) vulnerability was identified in the PSI (PressureStall Information) monitoring mechanism:BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140Read of size 8 at addr ffff3de3d50bd308 by task systemd/1psi_trigger_poll+0x3c/0x140cgroup_pressure_poll+0x70/0xa0cgroup_file_poll+0x8c/0x100kernfs_fop_poll+0x11c/0x1c0ep_item_poll.isra.0+0x188/0x2c0Allocated by task 1:cgroup_file_open+0x88/0x388kernfs_fop_open+0x73c/0xaf0do_dentry_open+0x5fc/0x1200vfs_open+0xa0/0x3f0do_open+0x7e8/0xd08path_openat+0x2fc/0x6b0do_filp_open+0x174/0x368Freed by task 8462:cgroup_file_release+0x130/0x1f8kernfs_drain_open_files+0x17c/0x440kernfs_drain+0x2dc/0x360kernfs_show+0x1b8/0x288cgroup_file_show+0x150/0x268cgroup_pressure_write+0x1dc/0x340cgroup_file_write+0x274/0x548Reproduction Steps:1. Open test/cpu.pressure and establish epoll monitoring2. Disable monitoring: echo 0 > test/cgroup.pressure3. Re-enable monitoring: echo 1 > test/cgroup.pressureThe race condition occurs because:1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files()2. While epoll still holds reference to the file and continues polling3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->privepolling disable/enable cgroup.pressurefd=open(cpu.pressure)while(1)...epoll_waitkernfs_fop_pollkernfs_get_active = true echo 0 > cgroup.pressure... cgroup_file_show kernfs_show // inactive kn kernfs_drain_open_files cft->release(of); kfree(ctx); ...kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn);kernfs_fop_pollkernfs_get_active = truecgroup_file_pollpsi_trigger_poll// UAF...end: close(fd)To address this issue, introduce kernfs_get_active_of() for kernfs openfiles to obtain active references. This function will fail if the open filehas been released. Replace kernfs_get_active() with kernfs_get_active_of()to prevent further operations on released file descriptors.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: avoid accessing metadata when pointer is invalid in object_err()object_err() reports details of an object for further debugging, such asthe freelist pointer, redzone, etc. However, if the pointer is invalid,attempting to access object metadata can lead to a crash since it doesnot point to a valid object.One known path to the crash is when alloc_consistency_checks()determines the pointer to the allocated object is invalid because of afreelist corruption, and calls object_err() to report it. The debug codeshould report and handle the corruption gracefully and not crash in theprocess.In case the pointer is NULL or check_valid_pointer() returns false forthe pointer, only print the pointer value and skip accessing metadata.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask andalways allocate memory using the hardcoded GFP_KERNEL flag. This makesthem inconsistent with vmalloc(), which was recently extended to supportGFP_NOFS and GFP_NOIO allocations.Page table allocations performed during shadow population also ignore theexternal gfp_mask. To preserve the intended semantics of GFP_NOFS andGFP_NOIO, wrap the apply_to_page_range() calls into the appropriatememalloc scope.xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.There was a report herehttps://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.comThis patch: - Extends kasan_populate_vmalloc() and helpers to take gfp_mask; - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page(); - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore() around apply_to_page_range(); - Updates vmalloc.c and percpu allocator call sites accordingly.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.syzbot reported the splat below. [0]The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytesAt 5., the data is carried over to the next sendmsg() as it issmaller than the cork_bytes specified by bpf_msg_cork_bytes().Then, tcp_bpf_send_verdict() tries to allocate psock->cork to holdthe data, but this fails silently due to fault injection + __GFP_NOWARN.If the allocation fails, we need to revert the sk->sk_forward_allocchange done by sk_msg_alloc().Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocatepsock->cork.The "*copied" also needs to be updated such that a proper error canbe returned to the caller, sendmsg. It fails to allocate psock->cork.Nothing has been corked so far, so this patch simply sets "*copied"to 0.[0]:WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983Modules linked in:CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fcRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: anx7625: Fix NULL pointer dereference with early IRQIf the interrupt occurs before resource initialization is complete, theinterrupt handler/worker may access uninitialized data such as the I2Ctcpc_client device, potentially leading to NULL pointer dereference.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failedIf earlier opening of source graph fails (e.g. ADSP rejects due toincorrect audioreach topology), the graph is closed and"dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sinkgraph continues though and next call to q6apm_lpass_dai_prepare()receives dai_data->graph[dai->id]=NULL leading to NULL pointerexception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),which does not ensure that the delayed work item synctstamp_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_workremains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().Furthermore, the synctstamp_work is cyclic, the likelihood of triggeringthe bug is nonnegligible.A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAFThis is confirmed by a KASAN report:BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800aa09a18 by task bash/136...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled before the otx2_ptp isdeallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the OcteonTX2 PCI device in QEMU and introducedartificial delays within the otx2_sync_tstamp() function to increase thelikelihood of triggering the bug.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tls: make sure to abort the stream if headers are bogusNormally we wait for the socket to buffer up the whole recordbefore we service it. If the socket has a tiny buffer, however,we read out the data sooner, to prevent connection stalls.Make sure that we abort the connection when we find out latethat the record is actually invalid. Retrying the parsing isfine in itself but since we copy some more data each timebefore we parse we can overflow the allocated skb space.Constructing a scenario in which we're under pressure withoutenough data in the socket to parse the length upfront is quitehard. syzbot figured out a way to do this by serving us the headerin small OOB sends, and then filling in the recvbuf with a largenormal send.Make sure that tls_rx_msg_size() aborts strp, if we reachan invalid record there's really no way to recover.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the mcba_usb driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, mcba_usb_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN frame.This can result in a buffer overflow. The driver will consume cf->lenas-is with no further checks on these lines: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc);Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the sun4i_can driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, sun4ican_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN frame.This can result in a buffer overflow. The driver will consume cf->lenas-is with no further checks on this line: dlc = cf->len;Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs acouple line below when doing: for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + (dreg + i * 4));Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the sun4i_can driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, hi3110_hard_start_xmit() receives a CAN XL frame which it isnot able to correctly handle and will thus misinterpret it as a CANframe. The driver will consume frame->len as-is with no furtherchecks.This can result in a buffer overflow later on in hi3110_hw_tx() onthis line: memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);Here, frame->len corresponds to the flags field of the CAN XL frame.In our previous example, we set canxl_frame->flags to 0xff. Becausethe maximum expected length is 8, a buffer overflow of 247 bytesoccurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the etas_es58x driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, es58x_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN(FD)frame.This can result in a buffer overflow. For example, using the es581.4variant, the frame will be dispatched to es581_4_tx_can_msg(), gothrough the last check at the beginning of this function: if (can_is_canfd_skb(skb)) return -EMSGSIZE;and reach this line: memcpy(tx_can_msg->data, cf->data, cf->len);Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU orCANFD_MTU (depending on the device capabilities). By fixing the rootcause, this prevents the buffer overflow.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()If ab->fw.m3_data points to data, then fw pointer remains null.Further, if m3_mem is not allocated, then fw is dereferenced to bepassed to ath11k_err function.Replace fw->size by m3_len.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: fix races with imon_disconnect()Syzbot reports a KASAN issue as below:BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106print_address_description mm/kasan/report.c:317 [inline]print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433kasan_report+0xb1/0x1e0 mm/kasan/report.c:495__create_pipe include/linux/usb.h:1945 [inline]send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991vfs_write+0x2d7/0xdd0 fs/read_write.c:576ksys_write+0x127/0x250 fs/read_write.c:631do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdThe iMON driver improperly releases the usb_device reference inimon_disconnect without coordinating with active users of thedevice.Specifically, the fields usbdev_intf0 and usbdev_intf1 are notprotected by the users counter (ictx->users). During probe,imon_init_intf0 or imon_init_intf1 increments the usb_devicereference count depending on the interface. However, duringdisconnect, usb_put_dev is called unconditionally, regardless ofactual usage.As a result, if vfd_write or other operations are still inprogress after disconnect, this can lead to a use-after-free ofthe usb_device pointer.Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1)...while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAFGuard access to usbdev_intf0 and usbdev_intf1 after disconnect bychecking ictx->disconnected in all writer paths. Add early returnwith -ENODEV in send_packet(), vfd_write(), lcd_write() anddisplay_open() if the device is no longer present.Set and read ictx->disconnected under ictx->lock to ensure memorysynchronization. Acquire the lock in imon_disconnect() before settingthe flag to synchronize with any ongoing operations.Ensure writers exit early and safely after disconnect before the USBcore proceeds with cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:media: tuner: xc5000: Fix use-after-free in xc5000_releaseThe original code uses cancel_delayed_work() in xc5000_release(), whichdoes not guarantee that the delayed work item timer_sleep has fullycompleted if it was already running. This leads to use-after-free scenarioswhere xc5000_release() may free the xc5000_priv while timer_sleep is stillactive and attempts to dereference the xc5000_priv.A typical race condition is illustrated below:CPU 0 (release thread) | CPU 1 (delayed work callback)xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the timer_sleep is properly canceled before the xc5000_priv memoryis deallocated.A deadlock concern was considered: xc5000_release() is called in a processcontext and is not holding any locks that the timer_sleep work item mightalso need. Therefore, the use of the _sync() variant is safe here.This bug was initially identified through static analysis.[hverkuil: fix typo in Subject: tunner -> tuner]
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probeThe state->timer is a cyclic timer that schedules work_i2c_poll anddelayed_work_enable_hotplug, while rearming itself. Using timer_delete()fails to guarantee the timer isn't still running when destroyed, similarlycancel_delayed_work() cannot ensure delayed_work_enable_hotplug hasterminated if already executing. During probe failure after timerinitialization, these may continue running as orphans and reference thealready-freed tc358743_state object through tc358743_irq_poll_timer.The following is the trace captured by KASAN.BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace timer_delete() with timer_delete_sync() and cancel_delayed_work()with cancel_delayed_work_sync() to ensure proper termination of timer andwork items before resource cleanup.This bug was initially identified through static analysis. For reproductionand testing, I created a functional emulation of the tc358743 device via akernel module and introduced faults through the debugfs interface.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_removeThe original code uses cancel_delayed_work() in flexcop_pci_remove(), whichdoes not guarantee that the delayed work item irq_check_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere flexcop_pci_remove() may free the flexcop_device while irq_check_workis still active and attempts to dereference the device.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAFThis is confirmed by a KASAN report:==================================================================BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff8880093aa8c8 by task bash/135...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executing delayedwork has finished before the device memory is deallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the B2C2 FlexCop PCI device in QEMU and introducedartificial delays within the flexcop_pci_irq_check_work() function toincrease the likelihood of triggering the bug.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_freeThe previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly atremoval") patched a UAF issue caused by the error timer.However, because the error timer kill added in this patch occurs after theendpoint delete, a race condition to UAF still occurs, albeit rarely.Additionally, since kill-cleanup for urb is also missing, freed memory canbe accessed in interrupt context related to urb, which can cause UAF.Therefore, to prevent this, error timer and urb must be killed beforefreeing the heap memory.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix potential null pointer dereference in afs_put_serverafs_put_server() accessed server->debug_id before the NULL check, whichcould lead to a null pointer dereference. Move the debug_id assignment,ensuring we never dereference a NULL server pointer.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: Fix null dereference in hdmi teardownpci_set_drvdata sets the value of pdev->driver_data to NULL,after which the driver_data obtained from the same dev isdereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev isextracted from it. To prevent this, swap these calls.Found by Linux Verification Center (linuxtesting.org) with Svacer.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: audioreach: fix potential null pointer dereferenceIt is possible that the topology parsing functionaudioreach_widget_load_module_common() could return NULL or an errorpointer. Add missing NULL check so that we do not dereference it.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: Take a reference on the task in struct vhost_task.vhost_task_create() creates a task and keeps a reference to itstask_struct. That task may exit early via a signal and its task_structwill be released.A pending vhost_task_wake() will then attempt to wake the task andaccess a task_struct which is no longer there.Acquire a reference on the task_struct while creating the thread andrelease the reference while the struct vhost_task itself is removed.If the task exits early due to a signal, then the vhost_task_wake() willstill access a valid task_struct. The wake is safe and will be skippedin this case.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: Check return value of platform_get_resource()platform_get_resource() returns NULL in case of failure, so check itsreturn value and propagate the error in order to prevent NULL pointerdereference.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULLcheck, which could lead to a null pointer dereference. Move the pruassignment, ensuring we never dereference a NULL rproc pointer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: fix possible map leak in fastrpc_put_argscopy_to_user() failure would cause an early return without cleaning upthe fdlist, which has been updated by the DSP. This could lead to mapleak. Fix this by redirecting to a cleanup path on failure, ensuringthat all mapped buffers are properly released before returning.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't validSkip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIPisn't valid, e.g. because KVM is running with nrips=false. SVM mustdecode and emulate to skip the instruction if the CPU doesn't provide thenext RIP, and getting the instruction bytes to decode requires readingguest memory. Reading guest memory through the emulator can fault, i.e.can sleep, which is disallowed since the fastpath handlers run with IRQsdisabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but withdifferent justification (KVM now grabs SRCU when skipping the instructionfor other reasons).
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/ksm: fix flag-dropping behavior in ksm_madvisesyzkaller discovered the following crash: (kernel BUG)[ 44.607039] ------------[ cut here ]------------[ 44.607422] kernel BUG at mm/userfaultfd.c:2067![ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460[ 44.617726] Call Trace:[ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0[ 44.620976] __fput+0x3f9/0xb60[ 44.621240] fput_close_sync+0x110/0x210[ 44.622222] __x64_sys_close+0x8f/0x120[ 44.622530] do_syscall_64+0x5b/0x2f0[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 44.623244] RIP: 0033:0x7f365bb3f227Kernel panics because it detects UFFD inconsistency duringuserfaultfd_release_all(). Specifically, a VMA which has a valid pointerto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.The inconsistency is caused in ksm_madvise(): when user calls madvise()with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,it accidentally clears all flags stored in the upper 32 bits ofvma->vm_flags.Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int andint are 32-bit wide. This setup causes the following mishap during the &=~VM_MERGEABLE assignment.VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is thenpromoted to unsigned long before the & operation. This promotion fillsupper 32 bits with leading 0s, as we're doing unsigned conversion (andeven for a signed conversion, this wouldn't help as the leading bit is 0).& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffffinstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clearsthe upper 32-bits of its value.Fix it by changing `VM_MERGEABLE` constant to unsigned long, using theBIT() macro.Note: other VM_* flags are not affected: This only happens to theVM_MERGEABLE flag, as the other VM_* flags are all constants of type intand after ~ operation, they end up with leading 1 and are thus convertedto unsigned long with leading 1s.Note 2:After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this isno longer a kernel BUG, but a WARNING at the same place:[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067but the root-cause (flag-drop) remains the same.[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Let userspace take care of interrupt maskRemove the logic to set interrupt mask by default in uio_hv_genericdriver as the interrupt mask value is supposed to be controlledcompletely by the user space. If the mask bit gets changedby the driver, concurrently with user mode operating on the ring,the mask bit may be set when it is supposed to be clear, and theuser-mode driver will miss an interrupt which will cause a hang.For eg- when the driver sets inbound ring buffer interrupt mask to 1,the host does not interrupt the guest on the UIO VMBus channel.However, setting the mask does not prevent the host from putting amessage in the inbound ring buffer. So let's assume that happens,the host puts a message into the ring buffer but does not interrupt.Subsequently, the user space code in the guest sets the inbound ringbuffer interrupt mask to 0, saying "Hey, I'm ready for interrupts".User space code then calls pread() to wait for an interrupt.Then one of two things happens:* The host never sends another message. So the pread() waits forever.* The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.This could be easily reproduced in hv_fcopy_uio_daemon if we delaysetting interrupt mask to 0.Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,there's a race condition. Once user space empties the inbound ringbuffer, but before user space sets interrupt_mask to 0, the host couldput another message in the ring buffer but it wouldn't interrupt.Then the next pread() would hang.Fix these by removing all instances where interrupt_mask is changed,while keeping the one in set_event() unchanged to enable userspacecontrol the interrupt mask by writing 0/1 to /dev/uioX.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Modify the return value checkThe return value of copy_from_iter and copy_to_iter can't be negative,check whether the copied lengths are equal.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Disallow dirty tracking if incoherent page walkDirty page tracking relies on the IOMMU atomically updating the dirty bitin the paging-structure entry. For this operation to succeed, the paging-structure memory must be coherent between the IOMMU and the CPU. Inanother word, if the iommu page walk is incoherent, dirty page trackingdoesn't work.The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault."To prevent an IOMMU from being incorrectly configured for dirty pagetracking when it is operating in an incoherent mode, mark SSADS assupported only when both ecap_slads and ecap_smpwc are supported.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: Return NULL pointer for allocation failuresWhen the TRBE driver fails to allocate a buffer, it currently returnsthe error code "-ENOMEM". However, the caller etm_setup_aux() onlychecks for a NULL pointer, so it misses the error. As a result, thedriver continues and eventually causes a kernel panic.Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() onallocation failures. This allows that the callers can properly handlethe failure.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix race in do_task() when drainingWhen do_task() exhausts its iteration budget (!ret), it sets the stateto TASK_STATE_IDLE to reschedule, without a secondary check on thecurrent task->state. This can overwrite the TASK_STATE_DRAINING stateset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().While state changes are protected by a spinlock, both rxe_cleanup_task()and rxe_disable_task() release the lock while waiting for the task tofinish draining in the while(!is_done(task)) loop. The race occurs ifdo_task() hits its iteration limit and acquires the lock in this window.The cleanup logic may then proceed while the task incorrectlyreschedules itself, leading to a potential use-after-free.This bug was introduced during the migration from tasklets to workqueues,where the special handling for the draining case was lost.Fix this by restoring the original pre-migration behavior. If the state isTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 toforce a new loop iteration. This allows the task to finish its work, sothat a subsequent iteration can reach the switch statement and correctlytransition the state to TASK_STATE_DRAINED, stopping the task as intended.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regsWhen the initialization of qm->debug.acc_diff_reg fails,the probe process does not exit. However, after qm->debug.qm_diff_regs isfreed, it is not set to NULL. This can lead to a double free when theremove process attempts to free it again. Therefore, qm->debug.qm_diff_regsshould be set to NULL after it is freed.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:pps: fix warning in pps_register_cdev when register device failSimilar to previous commit 2a934fdb01db ("media: v4l2-dev: fix errorhandling in __video_register_device()"), the release hook should be setbefore device_register(). Otherwise, when device_register() return errorand put_device() try to callback the release function, the below warningmay happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),pps_register_cdev() call device_create() to create pps->dev, which willinit dev->release to device_create_release(). Now the comment is outdated,just remove it.Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removedin pps_register_source() to avoid a double free in the failure case.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don't block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when openinga DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().If basic mode is used it calls gsm_modem_upd_via_msc() and itcannot block the input queue by waiting the response to comeinto the same input queue.Instead allow sending Modem Status Command without waiting for remoteend to respond. Define a new function gsm_modem_send_initial_msc()for this purpose. As MSC is only valid for basic encoding, it doesnot do anything for advanced or when convergence layer type 2 is used.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Define a proc_layoutcommit for the FlexFiles layout typeAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIToperation on a FlexFiles layout.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix missing pointer check in hda_component_manager_init functionThe __component_match_add function may assign the 'matchptr' pointerthe value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.The call stack leading to the error looks like this:hda_component_manager_init|-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign|-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereferenceAdd IS_ERR() check to prevent the crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state()Return value of a function acpi_evaluate_dsm() is dereferenced withoutchecking for NULL, but it is usually checked for this function.acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returnsacpi_status other than ACPI_SUCCESS, so add a check to prevent the crach.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlockPrevent USB runtime PM (autosuspend) for AX88772* in bind.usbnet enables runtime PM (autosuspend) by default, so disabling it viathe usb_driver flag is ineffective. On AX88772B, autosuspend shows nomeasurable power saving with current driver (no link partner, adminup/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib poweringthe PHY off on admin-down, not from USB autosuspend.The real hazard is that with runtime PM enabled, ndo_open() (under RTNL)may synchronously trigger autoresume (usb_autopm_get_interface()) intoasix_resume() while the USB PM lock is held. Resume paths then invokephylink/phylib and MDIO, which also expect RTNL, leading to possibledeadlocks or PM lock vs MDIO wake issues.To avoid this, keep the device runtime-PM active by taking a usagereference in ax88772_bind() and dropping it in unbind(). A non-zero PMusage count blocks runtime suspend regardless of userspace policy(.../power/control - pm_runtime_allow/forbid), making this approachrobust against sysfs overrides.Holding a runtime-PM usage ref does not affect system-wide suspend;system sleep/resume callbacks continue to run as before.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: ks-sa - fix division by zero in ks_sa_rng_initFix division by zero in ks_sa_rng_init caused by missing clockpointer initialization. The clk_get_rate() call is performed onan uninitialized clk pointer, resulting in division by zero whencalculating delay values.Add clock initialization code before using the clock. drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) whichwould lead to a error pointer dereference. Use IS_ERR_OR_NULL() to checkthat the pointer is valid.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
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:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() pathsThe usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()path is very broken.sys_prlimit64() does get_task_struct(tsk) but this only protects task_structitself. If tsk != current and tsk is not a leader, this process can exit/execand task_lock(tsk->group_leader) may use the already freed task_struct.Another problem is that sys_prlimit64() can race with mt-exec which changes->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)->group_leader may change between task_lock() and task_unlock().Change sys_prlimit64() to take tasklist_lock when necessary. This is notnice, but I don't see a better fix for -stable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: Rework user message limit handlingThe limit on the number of user messages had a number of issues,improper counting in some cases and a use after free.Restructure how this is all done to handle more in the receive messageallocation routine, so all refcouting and user message limit countsare done in that routine. It's a lot cleaner and safer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()The syzbot reported issue in hfs_find_set_zero_bits():=====================================================BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025=====================================================The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get():HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL);Finally, it can trigger the reported issue because kmalloc()doesn't clear the allocated memory. If allocated memory containsonly zeros, then everything will work pretty fine.But if the allocated memory contains the "garbage", thenit can affect the bitmap operations and it triggersthe reported issue.This patch simply exchanges the kmalloc() on kzalloc()with the goal to guarantee the correctness of bitmap operations.Because, newly created allocation bitmap should have allavailable blocks free. Potentially, initialization bitmap's readoperation could not fill the whole allocated memory and"garbage" in the not initialized memory will be the reason ofvolume coruptions and file system driver bugs.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:devlink: rate: Unset parent pointer in devl_rate_nodes_destroyThe function devl_rate_nodes_destroy is documented to "Unset parent forall rate objects". However, it was only calling the driver-specific`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementingthe parent's refcount, without actually setting the`devlink_rate->parent` pointer to NULL.This leaves a dangling pointer in the `devlink_rate` struct, which causerefcount error in netdevsim[1] and mlx5[2]. In addition, this isinconsistent with the behavior of `devlink_nl_rate_parent_node_set`,where the parent pointer is correctly cleared.This patch fixes the issue by explicitly setting `devlink_rate->parent`to NULL after notifying the driver, thus fulfilling the function'sdocumented behavior for all rate objects.[1]repro steps:echo 1 > /sys/bus/netdevsim/new_devicedevlink dev eswitch set netdevsim/netdevsim1 mode switchdevecho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfsdevlink port function rate add netdevsim/netdevsim1/test_nodedevlink port function rate set netdevsim/netdevsim1/128 parent test_nodeecho 1 > /sys/bus/netdevsim/del_devicedmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2]devlink dev eswitch set pci/0000:08:00.0 mode switchdevdevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000devlink port function rate add pci/0000:08:00.0/group1devlink port function rate set pci/0000:08:00.0/32768 parent group1modprobe -r mlx5_ib mlx5_fwctl mlx5_coredmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: remove never-working support for setting nsh fieldsThe validation of the set(nsh(...)) action is completely wrong.It runs through the nsh_key_put_from_nlattr() function that is thesame function that validates NSH keys for the flow match and thepush_nsh() action. However, the set(nsh(...)) has a very differentmemory layout. Nested attributes in there are doubled in size incase of the masked set(). That makes proper validation impossible.There is also confusion in the code between the 'masked' flag, thatsays that the nested attributes are doubled in size containing boththe value and the mask, and the 'is_mask' that says that the valuewe're parsing is the mask. This is causing kernel crash on trying towrite into mask part of the match with SW_FLOW_KEY_PUT() duringvalidation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe third issue with this process is that while trying to convertthe non-masked set into masked one, validate_set() copies and doublesthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nestedattributes. It should be copying each nested attribute and doublingthem in size independently. And the process must be properly reversedduring the conversion back from masked to a non-masked variant duringthe flow dump.In the end, the only two outcomes of trying to use this action areeither validation failure or a kernel crash. And if somehow someonemanages to install a flow with such an action, it will most definitelynot do what it is supposed to, since all the keys and the masks aremixed up.Fixing all the issues is a complex task as it requires re-writingmost of the validation code.Given that and the fact that this functionality never worked sinceintroduction, let's just remove it altogether. It's better tore-introduce it later with a proper implementation instead of tryingto fix it in stable releases.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dyingWhen unbinding a memslot from a guest_memfd instance, remove the bindingseven if the guest_memfd file is dying, i.e. even if its file refcount hasgone to zero. If the memslot is freed before the file is fully released,nullifying the memslot side of the binding in kvm_gmem_release() willwrite to freed memory, as detected by syzbot+KASAN: ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022 CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 __fput+0x44c/0xa70 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbeeff8efc9 Allocated by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2533 [inline] slab_free mm/slub.c:6622 [inline] kfree+0x19a/0x6d0 mm/slub.c:6829 kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fDeliberately don't acquire filemap invalid lock when the file is dying asthe lifecycle of f_mapping is outside the purview of KVM. Dereferencingthe mapping is *probably* fine, but there's no need to invalidate anythingas memslot deletion is responsible for zapping SPTEs, and the only codethat can access the dying file is kvm_gmem_release(), whose core code ismutual---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix improper check of dentry.stream.valid_sizeWe found an infinite loop bug in the exFAT file system that can lead to aDenial-of-Service (DoS) condition. When a dentry in an exFAT filesystem ismalformed, the following system calls - SYS_openat, SYS_ftruncate, andSYS_pwrite64 - can cause the kernel to hang.Root cause analysis shows that the size validation code in exfat_find()does not check whether dentry.stream.valid_size is negative. As a result,the system calls mentioned above can succeed and eventually trigger the DoSissue.This patch adds a check for negative dentry.stream.valid_size to preventthis vulnerability.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAMOtherwise accessing them can cause a crash.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:9p/trans_fd: p9_fd_request: kick rx thread if EPOLLINp9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq)if list_empty(&m->req_list).However, if the pipe is full, we need to read more data and this used towork prior to commit aaec5a95d59615 ("pipe_read: don't wake up the writerif the pipe is still full").p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (beforethe commit above) triggered the unnecessary wakeup. This wakeup callsp9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux()will notice EPOLLIN and schedule_work(&m->rq).This no longer happens after the optimization above, change p9_fd_request()to use p9_poll_mux() instead of only checking for EPOLLOUT.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Sync pending IRQ work before freeing ring bufferFix a race where irq_work can be queued in bpf_ringbuf_commit()but the ring buffer is freed before the work executes.In the syzbot reproducer, a BPF program attached to sched_switchtriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring bufferis freed before this work executes, the irq_work thread may accessesfreed memory.Calling `irq_work_sync(&rb->work)` ensures that all pending irq_workcomplete before freeing the buffer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_close_cached_fid()find_or_create_cached_dir() could grab a new reference after kref_put()had seen the refcount drop to zero but before cfid_list_lock is acquiredin smb2_close_cached_fid(), leading to use-after-free.Switch to kref_put_lock() so cfid_release() is called withcfid_list_lock held, closing that gap.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix mmap write lock not releaseIf mmap write lock is taken while draining retry fault, mmap write lockis not released because svm_range_restore_pages calls mmap_read_unlockthen returns. This causes deadlock and system hangs later because mmapread or write lock cannot be taken.Downgrade mmap write lock to read lock if draining retry fault fix thisbug.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix infinite loop in __insert_extent_tree()When we get wrong extent info data, and look up extent_node in rb tree,it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this byreturn NULL and print some kernel messages in that case.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()which causes the code to proceed with NULL clock pointers. The currentlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for bothvalid pointers and NULL, leading to potential NULL pointer dereferencein clk_get_rate().Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:"The error code within @ptr if it is an error pointer; 0 otherwise."This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULLpointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to becalled when of_clk_get() returns NULL.Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for validpointers, preventing potential NULL pointer dereference in clk_get_rate().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: fix the deadlock of enetc_mdio_lockAfter applying the workaround for err050089, the LS1028A platformexperiences RCU stalls on RT kernel. This issue is caused by therecursive acquisition of the read lock enetc_mdio_lock. Here list someof the call stacks identified under the enetc_poll path that may lead toa deadlock:enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdioAfter enetc_poll acquires the read lock, a higher-priority writer attemptsto acquire the lock, causing preemption. The writer detects that aread lock is already held and is scheduled out. However, readers underenetc_poll cannot acquire the read lock again because a writer is alreadywaiting, leading to a thread hang.Currently, the deadlock is avoided by adjusting enetc_lock_mdio to preventrecursive lock acquisition.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQXDP programs can change the layout of an xdp_buff throughbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the drivercannot assume the size of the linear data area nor fragments. Fix thebug in mlx5 by generating skb according to xdp_buff after XDP programsrun.Currently, when handling multi-buf XDP, the mlx5 driver assumes thelayout of an xdp_buff to be unchanged. That is, the linear data areacontinues to be empty and fragments remain the same. This may causethe driver to generate erroneous skb or triggering a kernelwarning. When an XDP program added linear data throughbpf_xdp_adjust_head(), the linear data will be ignored asmlx5e_build_linear_skb() builds an skb without linear data and thenpull data from fragments to fill the linear data area. When an XDPprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),the delta passed to __pskb_pull_tail() may exceed the actual nonlineardata size and trigger the BUG_ON in it.To fix the issue, first record the original number of fragments. If thenumber of fragments changes after the XDP program runs, rewind the endfragment pointer by the difference and recalculate the truesize. Then,build the skb with the linear data area matching the xdp_buff. Finally,only pull data in if there is non-linear data and fill the linear partup to 256 bytes.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/sysfb: Do not dereference NULL pointer in plane resetThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do notderef that pointer, but forward NULL to the other plane-reset helpers.Clears plane->state to NULL.v2:- fix typo in commit description (Javier)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlockThe parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure XFD state on signal deliverySean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Chao further identified [2] a reproducible scenario involving signaldelivery: a non-AMX task is preempted by an AMX-enabled task whichmodifies the XFD MSR.When the non-AMX task resumes and reloads XSTATE with init values,a warning is triggered due to a mismatch between fpstate::xfd and theCPU's current XFD state. fpu__clear_user_states() does not currentlyre-synchronize the XFD state after such preemption.Invoke xfd_update_state() which detects and corrects the mismatch ifthere is a dynamic feature.This also benefits the sigreturn path, as fpu__restore_sig() may callfpu__clear_user_states() when the sigframe is inaccessible.[ dhansen: minor changelog munging ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: fix possible deadlock while configuring policyFollowing deadlock can be triggered easily by lockdep:WARNING: possible circular locking dependency detected6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted------------------------------------------------------check/1334 is trying to acquire lock:ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180but task is already holding lock:ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7eother info that might help us debug this:Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);Root cause is that queue_usage_counter is grabbed with rq_qos_mutexheld in blkg_conf_prep(), while queue should be freezed beforerq_qos_mutex from other context.The blk_queue_enter() from blkg_conf_prep() is used to protect againstpolicy deactivation, which is already protected with blkcg_mutex, henceconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,consider that blkcg_mutex is held after queue is freezed from policydeactivation, also convert blkg_alloc() to use GFP_NOIO.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: use netdev_warn() instead of netdev_WARN()netdev_WARN() uses WARN/WARN_ON to print a backtrace along withfile and line information. In this case, udp_tunnel_nic_register()returning an error is just a failed operation, not a kernel bug.udp_tunnel_nic_register() can fail due to a memory allocationfailure (kzalloc() or udp_tunnel_nic_alloc()).This is a normal runtime error and not a kernel bug.Replace netdev_WARN() with netdev_warn() accordingly.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add bpf_prog_run_data_pointers()syzbot found that cls_bpf_classify() is able to changetc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:Extend qdisc control block with tc control block"), which added a wronginteraction with db58ba459202 ("bpf: wire in data and data_end forcls_act_bpf").drop_reason was added later.Add bpf_prog_run_data_pointers() helper to save/restore the net_schedstorage colliding with BPF data_meta/data_end.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: remove two invalid BUG_ON()sThose can be triggered trivially by userspace.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mlx5: Fix default values in create CQCurrently, CQs without a completion function are assigned themlx5_add_cq_to_tasklet function by default. This is problematic sinceonly user CQs created through the mlx5_ib driver are intended to usethis function.Additionally, all CQs that will use doorbells instead of polling forcompletions must call mlx5_cq_arm. However, the default CQ creation flowleaves a valid value in the CQ's arm_db field, allowing FW to sendinterrupts to polling-only CQs in certain corner cases.These two factors would allow a polling-only kernel CQ to be triggeredby an EQ interrupt and call a completion function intended only for userCQs, causing a null pointer exception.Some areas in the driver have prevented this issue with one-off fixesbut did not address the root cause.This patch fixes the described issue by adding defaults to the create CQflow. It adds a default dummy completion function to protect againstnull pointer exceptions, and it sets an invalid command sequence numberby default in kernel CQs to prevent the FW from sending an interrupt tothe CQ until it is armed. User CQs are responsible for their owninitialization values.Callers of mlx5_core_create_cq are responsible for changing thecompletion function and arming the CQ per their needs.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on errorMake knav_dma_open_channel consistently return NULL on error insteadof ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.hreturns NULL when the driver is disabled, but the driverimplementation does not even return NULL or ERR_PTR on failure,causing inconsistency in the users. This results in a crash innetcp_free_navigator_resources as followed (trimmed):Unhandled fault: alignment exception (0x221) at 0xfffffff2[fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000Internal error: : 221 [#1] SMP ARMModules linked in:CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONEHardware name: KeystonePC is at knav_dma_close_channel+0x30/0x19cLR is at netcp_free_navigator_resources+0x2c/0x28c[... TRIM...]Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38[... TRIM...]Standardize the error handling by making the function return NULL onall error conditions. The API is used in just the netcp_core.c so theimpact is limited.Note, this change, in effect reverts commit 5b6cb43b4d62 ("net:ethernet: ti: netcp_core: return error while dma channel open issue"),but provides a less error prone implementation.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Fix proto fallback detection with BPFThe sockmap feature allows bpf syscall from userspace, or basedon bpf sockops, replacing the sk_prot of sockets during protocol stackprocessing with sockmap's custom read/write interfaces.'''tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot'''When the server has MPTCP enabled but the client sends a TCP SYNwithout MPTCP, subflow_syn_recv_sock() performs a fallback on thesubflow, replacing the subflow sk's sk_prot with the native sk_prot.'''subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override()'''Then, this subflow can be normally used by sockmap, which replaces thenative sk_prot with sockmap's custom sk_prot. The issue occurs when theuser executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().Here, it uses sk->sk_prot to compare with the native sk_prot, but thisis incorrect when sockmap is used, as we may incorrectly setsk->sk_socket->ops.This fix uses the more generic sk_family for the comparison instead.Additionally, this also prevents a WARNING from occurring:result from ./scripts/decode_stacktrace.sh:------------[ cut here ]------------WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \(net/mptcp/protocol.c:4005)Modules linked in:...PKRU: 55555554Call Trace:do_accept (net/socket.c:1989)__sys_accept4 (net/socket.c:2028 net/socket.c:2057)__x64_sys_accept (net/socket.c:2067)x64_sys_call (arch/x86/entry/syscall_64.c:41)do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)RIP: 0033:0x7f87ac92b83d---[ end trace 0000000000000000 ]---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix gpu page fault after hibernation on PF passthroughOn PF passthrough environment, after hibernate and then resume, coralgemmwill cause gpu page fault.Mode1 reset happens during hibernate, but partition mode is not restoredon resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not rightafter resume. When CP access the MQD BO, wrong stride size is used,this will cause out of bound access on the MQD BO, resulting page fault.The fix is to ensure gfx_v9_4_3_switch_compute_partition() is calledwhen resume from a hibernation.KFD resume is called separately during a reset recovery or resume fromsuspend sequence. Hence it's not required to be called as part ofpartition switch.(cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: restore write access before closing files opened by open_exec()bm_register_write() opens an executable file using open_exec(), whichinternally calls do_open_execat() and denies write access on the file toavoid modification while it is being executed.However, when an error occurs, bm_register_write() closes the file usingfilp_close() directly. This does not restore the write permission, whichmay cause subsequent write operations on the same file to fail.Fix this by calling exe_file_allow_write_access() before filp_close() torestore the write permission properly.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replacedWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTninstruction, discard the exception and retry the instruction if the codestream is changed (e.g. by a different vCPU) between when the CPUexecutes the instruction and when KVM decodes the instruction to get thenext RIP.As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-injectINT3/INTO instead of retrying the instruction"), failure to verify thatthe correct INTn instruction was decoded can effectively clobber gueststate due to decoding the wrong instruction and thus specifying thewrong next RIP.The bug most often manifests as "Oops: int3" panics on static branchchecks in Linux guests. Enabling or disabling a static branch in Linuxuses the kernel's "text poke" code patching mechanism. To modify codewhile other CPUs may be executing that code, Linux (temporarily)replaces the first byte of the original instruction with an int3 (opcode0xcc), then patches in the new code stream except for the first byte,and finally replaces the int3 with the first byte of the new codestream. If a CPU hits the int3, i.e. executes the code while it's beingmodified, then the guest kernel must look up the RIP to determine how tohandle the #BP, e.g. by emulating the new instruction. If the RIP isincorrect, then this lookup fails and the guest kernel panics.The bug reproduces almost instantly by hacking the guest kernel torepeatedly check a static branch[1] while running a drgn script[2] onthe host to constantly swap out the memory containing the guest's TSS.[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bfs: Reconstruct file type when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 32bits "mode" field loaded from disk are corruptedor when the 32bits "attributes" field loaded from disk are corrupted.A documentation says that BFS uses only lower 9 bits of the "mode" field.But I can't find an explicit explanation that the unused upper 23 bits(especially, the S_IFMT bits) are initialized with 0.Therefore, ignore the S_IFMT bits of the "mode" field loaded from disk.Also, verify that the value of the "attributes" field loaded from disk iseither BFS_VREG or BFS_VDIR (because BFS supports only regular files andthe root directory).
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: fix fragment overflow handling in RX pathThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)fragments when handling large multi-descriptor packets. This causes anout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.The issue occurs because the driver doesn't check the total number offragments before calling skb_add_rx_frag(). When a packet requires morethan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,then all fragments are accounted for. And reusing the existing check toprevent the overflow earlier in the code path.This crash occurred in production with an Aquantia AQC113 10G NIC.Stack trace from production environment:```RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 4889 fa 83RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:fffffffe0a0c8000RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:0000000000037a40RBP: 0000000000000024 R08: 0000000000000000 R09:0000000000000021R10: 0000000000000848 R11: 0000000000000000 R12:ffffa9bec02a8e24R13: ffff925ad8615570 R14: 0000000000000000 R15:ffff925b22e80a00FS: 0000000000000000(0000)GS:ffff925e47880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:0000000000f72ef0PKRU: 55555554Call Trace:aq_ring_rx_clean+0x175/0xe60 [atlantic]? aq_ring_rx_clean+0x14d/0xe60 [atlantic]? aq_ring_tx_clean+0xdf/0x190 [atlantic]? kmem_cache_free+0x348/0x450? aq_vec_poll+0x81/0x1d0 [atlantic]? __napi_poll+0x28/0x1c0? net_rx_action+0x337/0x420```Changes in v4:- Add Fixes: tag to satisfy patch validation requirements.Changes in v3:- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: ip22zilog: Use platform device for probingAfter commit 84a9582fd203 ("serial: core: Start managing serial controllersto enable runtime PM") serial drivers need to provide a device instruct uart_port.dev otherwise an oops happens. To fix this issuefor ip22zilog driver switch driver to a platform driver and setupthe serial device in sgi-ip22 code.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:lan966x: Fix sleeping in atomic contextThe following warning was seen when we try to connect using ssh to the device.BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbearpreempt_count: 1, expected: 0INFO: lockdep is turned off.CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONETainted: [W]=WARNHardware name: Generic DT based systemCall trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1cException stack(0xf0b11fa8 to 0xf0b11ff0)1fa0: 00000001 00001000 00000008 be9048d8 00001000 000000011fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 000000011fe0: 0005404c be9048c0 00018684 b6ec2cd8It seems that we are using a mutex in a atomic context which is wrong.Change the mutex with a spinlock.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Avoid crash due to unaligned access in unwinderGuenter Roeck reported this kernel crash on his emulated B160L machine:Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe.isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>] ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>] __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0While creating the stack trace, the unwinder uses the stack pointer to guessthe previous frame to read the previous stack pointer from memory. The crashhappens, because the unwinder tries to read from unaligned memory and as suchtriggers the unalignment trap handler which then leads to the spinlockrecursion and finally to a deadlock.Fix it by checking the alignment before accessing the memory.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_cake: Fix incorrect qlen reduction in cake_dropIn cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlenand backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumesthat the parent qdisc will enqueue the current packet. However, thisassumption breaks when cake_enqueue() returns NET_XMIT_CN: the parentqdisc stops enqueuing current packet, leaving the tree qlen/backlogaccounting inconsistent. This mismatch can lead to a NULL dereference(e.g., when the parent Qdisc is qfq_qdisc).This patch computes the qlen/backlog delta in a more robust way byobserving the difference before and after the series of cake_drop()calls, and then compensates the qdisc tree accounting if cake_enqueue()returns NET_XMIT_CN.To ensure correct compensation when ACK thinning is enabled, a newvariable is introduced to keep qlen unchanged.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: microchip: Don't free uninitialized ksz_irqIf something goes wrong at setup, ksz_irq_free() can be called onuninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). Itleads to freeing uninitialized IRQ numbers and/or domains.Use dsa_switch_for_each_user_port_continue_reverse() in the error pathto iterate only over the fully initialized ports.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check skb->transport_header is set in bpf_skb_check_mtuThe bpf_skb_check_mtu helper needs to use skb->transport_header whenthe BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)The transport_header is not always set. There is a WARN_ON_ONCEreport when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +bpf_prog_test_run is used:WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skbFor a normal ingress skb (not test_run), skb_reset_transport_headeris performed but there is plan to avoid setting it as described incommit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").This patch fixes the bpf helper by checkingskb_transport_header_was_set(). The check is done just beforeskb->transport_header is used, to avoid breaking the existing bpf prog.The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Initialize allocated memory before useKMSAN reports: Multiple uninitialized values detected:- KMSAN: uninit-value in ntfs_read_hdr (3)- KMSAN: uninit-value in bcmp (3)Memory is allocated by __getname(), which is a wrapper forkmem_cache_alloc(). This memory is used before being properlycleared. Change kmem_cache_alloc() to kmem_cache_zalloc() toproperly allocate and clear memory before use.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:md: fix rcu protection in md_wakeup_threadWe attempted to use RCU to protect the pointer 'thread', but directlypassed the value when calling md_wakeup_thread(). This means that theRCU pointer has been acquired before rcu_read_lock(), which rendersrcu_read_lock() ineffective and could lead to a use-after-free.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check in __bpf_get_stackid()Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not let BPF test infra emit invalid GSO types to stackYinhao et al. reported that their fuzzer tool was able to trigger askb_warn_bad_offload() from netif_skb_features() -> gso_features_check().When a BPF program - triggered via BPF test infra - pushes the packetto the loopback device via bpf_clone_redirect() then mentioned offloadwarning can be seen. GSO-related features are then rightfully disabled.We get into this situation due to convert___skb_to_skb() settinggso_segs and gso_size but not gso_type. Technically, it makes sensethat this warning triggers since the GSO properties are malformed dueto the gso_type. Potentially, the gso_type could be marked non-trustworthythrough setting it at least to SKB_GSO_DODGY without any other specificassumptions, but that also feels wrong given we should not go furtherinto the GSO engine in the first place.The checks were added in 121d57af308d ("gso: validate gso_type in GSOhandlers") because there were malicious (syzbot) senders that combinea protocol with a non-matching gso_type. If we would want to drop suchpackets, gso_features_check() currently only returns feature flags vianetif_skb_features(), so one location for potentially dropping such skbscould be validate_xmit_unreadable_skb(), but then otoh it would bean additional check in the fast-path for a very corner case. Givenbpf_clone_redirect() is the only place where BPF test infra could emitsuch packets, lets reject them right there.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: Fix uninit buffer allocated by __getname()Fix uninit errors caused after buffer allocation given to 'de'; byinitializing the buffer with zeroes. The fix was found by using KMSAN.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: fix uninit memory after failed mi_read in mi_format_newFix a KMSAN un-init bug found by syzkaller.ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not beuptodate. We do not bring the buffer uptodate before setting it asuptodate. If the buffer were to not be uptodate, it could mean adding abuffer with un-init data to the mi record. Attempting to load that recordwill trigger KMSAN.Avoid this by setting the buffer as uptodate, if it's not already, byoverwriting it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:staging: most: remove broken i2c driverThe MOST I2C driver has been completely broken for five years withoutanyone noticing so remove the driver from staging.Specifically, commit 723de0f9171e ("staging: most: remove device frominterface structure") started requiring drivers to set the interfacedevice pointer before registration, but the I2C driver was never updatedwhich results in a NULL pointer dereference if anyone ever tries toprobe it.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix possible data races in gfs2_show_options()Some fields such as gt_logd_secs of the struct gfs2_tune are accessedwithout holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);And thus can cause data races when gfs2_show_options() and other functionssuch as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit;To fix these possible data races, the lock sdp->sd_tune.gt_spin isacquired before accessing the fields of gfs2_tune and released after theseaccesses.Further changes by Andreas:- Don't hold the spin lock over the seq_printf operations.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:HID: amd_sfh: Fix for shift-out-of-boundsShift operation of 'exp' and 'shift' variables exceeds the maximum numberof shift values in the u32 range leading to UBSAN shift-out-of-bounds....[ 6.120512] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50[ 6.120598] shift exponent 104 is too large for 64-bit type 'long unsigned int'[ 6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10[ 6.120665] Hardware name: AMD Birman-PHX/Birman-PHX, BIOS SFH_with_HPD_SEN.FD 04/05/2023[ 6.120667] Workqueue: events amd_sfh_work_buffer [amd_sfh][ 6.120687] Call Trace:[ 6.120690] [ 6.120694] dump_stack_lvl+0x48/0x70[ 6.120704] dump_stack+0x10/0x20[ 6.120707] ubsan_epilogue+0x9/0x40[ 6.120716] __ubsan_handle_shift_out_of_bounds+0x10f/0x170[ 6.120720] ? psi_group_change+0x25f/0x4b0[ 6.120729] float_to_int.cold+0x18/0xba [amd_sfh][ 6.120739] get_input_rep+0x57/0x340 [amd_sfh][ 6.120748] ? __schedule+0xba7/0x1b60[ 6.120756] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh][ 6.120764] amd_sfh_work_buffer+0x91/0x180 [amd_sfh][ 6.120772] process_one_work+0x229/0x430[ 6.120780] worker_thread+0x4a/0x3c0[ 6.120784] ? __pfx_worker_thread+0x10/0x10[ 6.120788] kthread+0xf7/0x130[ 6.120792] ? __pfx_kthread+0x10/0x10[ 6.120795] ret_from_fork+0x29/0x50[ 6.120804] ...Fix this by adding the condition to validate shift ranges.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a potential data corruptionWe must ensure that the subrequests are joined back into the head beforewe can retransmit a request. If the head was not on the commit lists,because the server wrote it synchronously, we still need to add it backto the retransmission list.Add a call that mirrors the effect of nfs_cancel_remove_inode() forO_DIRECT.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that's racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPEOn Google gs101, the number of UTP transfer request slots (nutrs) is 32,and in this case the driver ends up programming the UTRL_NEXUS_TYPEincorrectly as 0.This is because the left hand side of the shift is 1, which is of typeint, i.e. 31 bits wide. Shifting by more than that width results inundefined behaviour.Fix this by switching to the BIT() macro, which applies correct typecasting as required. This ensures the correct value is written toUTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shiftwarning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int'For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPEwrite.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix use-after-free caused by cyclic delayed workThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()to cancel the cyclic delayed work item ocelot->stats_work. However,cancel_delayed_work() may fail to cancel the work item if it is alreadyexecuting. While destroy_workqueue() does wait for all pending work itemsin the work queue to complete before destroying the work queue, it cannotprevent the delayed work item from being rescheduled within theocelot_check_stats_work() function. This limitation exists because thedelayed work item is only enqueued into the work queue after its timerexpires. Before the timer expiration, destroy_workqueue() has no visibilityof this pending work item. Once the work queue appears empty,destroy_workqueue() proceeds with destruction. When the timer eventuallyexpires, the delayed work item gets queued again, leading to the followingwarning:workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-statsWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0...RIP: 0010:__queue_work+0x875/0xaf0...RSP: 0018:ffff88806d108b10 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0Call Trace: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...The following diagram reveals the cause of the above warning:CPU 0 (remove) | CPU 1 (delayed work callback)mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAFThe above scenario actually constitutes a UAF vulnerability.The ocelot_stats_deinit() is only invoked when initializationfailure or resource destruction, so we must ensure that anydelayed work items cannot be rescheduled.Replace cancel_delayed_work() with disable_delayed_work_sync()to guarantee proper cancellation of the delayed work item andensure completion of any currently executing work before theworkqueue is deallocated.A deadlock concern was considered: ocelot_stats_deinit() is calledin a process context and is not holding any locks that the delayedwork item might also need. Therefore, the use of the _sync() variantis safe here.This bug was identified through static analysis. To reproduce theissue and validate the fix, I simulated ocelot-swit---truncated---
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}Cilium has a BPF egress gateway feature which forces outgoing K8s Podtraffic to pass through dedicated egress gateways which then SNAT thetraffic in order to interact with stable IPs outside the cluster.The traffic is directed to the gateway via vxlan tunnel in collect mdmode. A recent BPF change utilized the bpf_redirect_neigh() helper toforward packets after the arrival and decap on vxlan, which turned outover time that the kmalloc-256 slab usage in kernel was ever-increasing.The issue was that vxlan allocates the metadata_dst object and attachesit through a fake dst entry to the skb. The latter was never releasedthough given bpf_redirect_neigh() was merely setting the new dst entryvia skb_dst_set() without dropping an existing one first.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.
Packages affected:
docker > 0-0 (version in image is 28.4.0_ce-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Packages affected:
docker > 0-0 (version in image is 28.4.0_ce-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)
Packages affected:
openssh < 9.6p1-4.1 (version in image is 9.6p1-3.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
python311-urllib3 > 0-0 (version in image is 2.1.0-3.1).
Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
python311-urllib3 > 0-0 (version in image is 2.1.0-3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to detect potential corrupted nid in free_nid_listAs reported, on-disk footer.ino and footer.nid is the same andout-of-range, let's add sanity check on f2fs_alloc_nid() to detectany potential corruption in free_nid_list.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
vim-data-common > 0-0 (version in image is 9.1.1629-1.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: Skip DIMM enumeration on a disabled memory controllerWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ...This occurs because some BIOS may disable a memory controller if therearen't any memory DIMMs populated on this memory controller. The DIMMMTRregister of this disabled memory controller contains the invalid value~0, resulting in the call trace above.Fix this call trace by skipping DIMM enumeration on a disabled memorycontroller.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc: fix uaf in proc_readdir_de()Pde is erased from subdir rbtree through rb_erase(), but not set the nodeto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()set the erased node to EMPTY, then pde_subdir_next() will return NULL toavoid uaf access.We found an uaf issue while using stress-ng testing, need to run testcasegetdent and tun in the same time. The steps of the issue is as follows:1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.CPU 0 | CPU 1-------------------------------------------------------------------------traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Do not share the name pointer between componentsBy sharing 'name' directly, tearing down components may lead touse-after-free errors. Duplicate the name to avoid that.At the same time, update the order of operations - since commitcee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name viaconfig") the framework does not override component->name if set beforeinvoking the initializer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
containerd < 1.7.29-1.1 (version in image is 1.7.27-1.1).
Description: The IEEE 802.11 standard sometimes enables an adversary to trick a victim into connecting to an unintended or untrusted network with Home WEP, Home WPA3 SAE-loop. Enterprise 802.1X/EAP, Mesh AMPE, or FILS, aka an "SSID Confusion" issue. This occurs because the SSID is not always used to derive the pairwise master key or session keys, and because there is not a protected exchange of an SSID during a 4-way handshake.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
wpa_supplicant > 0-0 (version in image is 2.10-5.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:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability
Packages affected:
grub2 > 0-0 (version in image is 2.12~rc1-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
grub2 > 0-0 (version in image is 2.12~rc1-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
Packages affected:
grub2 > 0-0 (version in image is 2.12~rc1-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.
Packages affected:
grub2 > 0-0 (version in image is 2.12~rc1-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.
Packages affected:
grub2 > 0-0 (version in image is 2.12~rc1-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.
Packages affected:
glib2-tools < 2.76.2-10.1 (version in image is 2.76.2-9.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.
Packages affected:
grub2 > 0-0 (version in image is 2.12~rc1-7.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix memory leak in WMI firmware statsMemory allocated for firmware pdev, vdev and beacon statisticsare not released during rmmod.Fix it by calling ath11k_fw_stats_free() function before hardwareunregister.While at it, avoid calling ath11k_fw_stats_free() while processingthe firmware stats received in the WMI event because the local listis getting spliced and reinitialised and hence there are no elementsin the list after splicing.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}If the filename casefolding fails, we'll be leaking memory from thefscrypt_name struct, namely from the 'crypto_buf.name' member.Make sure we free it in the error path on both ext4_fname_setup_filename()and ext4_fname_prepare_lookup() functions.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_costadjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabledwhen unlock. DEADLOCK might happen if we have held other locks and disabledIRQ before invoking it.Fix it by using spin_lock_irqsave() instead, which can keep IRQ stateconsistent with before when unlock. ================================ WARNING: inconsistent lock state 5.10.0-02758-g8e5f91fd772f #26 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 {IN-HARDIRQ-W} state was registered at: __lock_acquire+0x3d7/0x1070 lock_acquire+0x197/0x4a0 __raw_spin_lock_irqsave _raw_spin_lock_irqsave+0x3b/0x60 bfq_idle_slice_timer_body bfq_idle_slice_timer+0x53/0x1d0 __run_hrtimer+0x477/0xa70 __hrtimer_run_queues+0x1c6/0x2d0 hrtimer_interrupt+0x302/0x9e0 local_apic_timer_interrupt __sysvec_apic_timer_interrupt+0xfd/0x420 run_sysvec_on_irqstack_cond sysvec_apic_timer_interrupt+0x46/0xa0 asm_sysvec_apic_timer_interrupt+0x12/0x20 irq event stamp: 837522 hardirqs last enabled at (837521): [] __raw_spin_unlock_irqrestore hardirqs last enabled at (837521): [] _raw_spin_unlock_irqrestore+0x3d/0x40 hardirqs last disabled at (837522): [] __raw_spin_lock_irq hardirqs last disabled at (837522): [] _raw_spin_lock_irq+0x43/0x50 softirqs last enabled at (835852): [] __do_softirq+0x558/0x8ec softirqs last disabled at (835845): [] asm_call_irq_on_stack+0xf/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&bfqd->lock); lock(&bfqd->lock); *** DEADLOCK *** 3 locks held by kworker/2:3/388: #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0 #1: ffff8881176bfdd8 ((work_completion)(&td->dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0 #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 stack backtrace: CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kthrotld blk_throtl_dispatch_work_fn Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x167 print_usage_bug valid_state mark_lock_irq.cold+0x32/0x3a mark_lock+0x693/0xbc0 mark_held_locks+0x9e/0xe0 __trace_hardirqs_on_caller lockdep_hardirqs_on_prepare.part.0+0x151/0x360 trace_hardirqs_on+0x5b/0x180 __raw_spin_unlock_irq _raw_spin_unlock_irq+0x24/0x40 spin_unlock_irq adjust_inuse_and_calc_cost+0x4fb/0x970 ioc_rqos_merge+0x277/0x740 __rq_qos_merge+0x62/0xb0 rq_qos_merge bio_attempt_back_merge+0x12c/0x4a0 blk_mq_sched_try_merge+0x1b6/0x4d0 bfq_bio_merge+0x24a/0x390 __blk_mq_sched_bio_merge+0xa6/0x460 blk_mq_sched_bio_merge blk_mq_submit_bio+0x2e7/0x1ee0 __submit_bio_noacct_mq+0x175/0x3b0 submit_bio_noacct+0x1fb/0x270 blk_throtl_dispatch_work_fn+0x1ef/0x2b0 process_one_work+0x83e/0x13f0 process_scheduled_works worker_thread+0x7e3/0xd80 kthread+0x353/0x470 ret_from_fork+0x1f/0x30
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:netlink: fix potential deadlock in netlink_set_err()syzbot reported a possible deadlock in netlink_set_err() [1]A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQsfor netlink_lock_table()") in netlink_lock_table()This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()which were not covered by cited commit.[1]WARNING: possible irq lock inversion dependency detected6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not taintedsyz-executor.2/23011 just changed the state of lock:ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2}and interrupts could create inverse lock ordering between them.other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); lock(&local->queue_stop_reason_lock); *** DEADLOCK ***
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:leds: led-core: Fix refcount leak in of_led_get()class_find_device_by_of_node() calls class_find_device(), it will takethe reference, use the put_device() to drop the reference when not needanymore.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix locking order in ivpu_job_submitFix deadlock in job submission and abort handling.When a thread aborts currently executing jobs due to a fault,it first locks the global lock protecting submitted_jobs (#1).After the last job is destroyed, it proceeds to release the related contextand locks file_priv (#2). Meanwhile, in the job submission thread,the file_priv lock (#2) is taken first, and then the submitted_jobslock (#1) is obtained when a job is added to the submitted jobs list. CPU0 CPU1 ---- ---- (for example due to a fault) (jobs submissions keep coming) lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2This order of locking causes a deadlock. To resolve this issue,change the order of locking in ivpu_job_submit().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lockWhen netpoll is enabled, calling pr_warn_once() while holdingkmemleak_lock in mem_pool_alloc() can cause a deadlock due to lockinversion with the netconsole subsystem. This occurs becausepr_warn_once() may trigger netpoll, which eventually leads to__alloc_skb() and back into kmemleak code, attempting to reacquirekmemleak_lock.This is the path for the deadlock.mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);Fix this by setting a flag and issuing the pr_warn_once() afterkmemleak_lock is released.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix NULL pointer dereference in __dm_suspend()There is a race condition between dm device suspend and table load thatcan lead to null pointer dereference. The issue occurs when suspend isinvoked before table load completes:BUG: kernel NULL pointer dereference, address: 0000000000000054Oops: 0000 [#1] PREEMPT SMP PTICPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0The issue can be triggered as below:T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1)dm_stop_queue / dm_wait_for_completion=> q->tag_set NULL pointer! (2) => q->tag_set = set; (3)Fix this by checking if a valid table (map) exists before performingrequest-based suspend and waiting for target I/O. When map is NULL,skip these table-dependent suspend steps.Even when map is NULL, no I/O can reach any target because there isno table loaded; I/O submitted in this state will fail early in theDM layer. Skipping the table-dependent suspend logic in this caseis safe and avoids NULL pointer dereferences.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: verify orphan file size is not too bigIn principle orphan file can be arbitrarily large. However orphan replayneeds to traverse it all and we also pin all its buffers in memory. Thusfilesystems with absurdly large orphan files can lead to big amounts ofmemory consumed. Limit orphan file size to a sane value and also usekvmalloc() for allocating array of block descriptor structures to avoidlarge order allocations for sane but large orphan files.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: client: fix memory leak in smb3_fs_context_parse_paramThe user calls fsconfig twice, but when the program exits, free() onlyfrees ctx->source for the second fsconfig, not the first.Regarding fc->source, there is no code in the fs context related to itsmemory reclamation.To fix this memory leak, release the source memory corresponding to ctxor fc before each parsing.syzbot reported:BUG: memory leakunreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444BUG: memory leakunreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smb/server: fix possible refcount leak in smb2_sess_setup()Reference count of ksmbd_session will leak when session need reconnect.Fix this by adding the missing ksmbd_user_session_put().
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lockblk_mq_{add,del}_queue_tag_set() functions add and remove queues fromtagset, the functions make sure that tagset and queues are marked asshared when two or more queues are attached to the same tagset.Initially a tagset starts as unshared and when the number of addedqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared alongwith all the queues attached to it. When the number of attached queuesdrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset andthe remaining queues as unshared.Both functions need to freeze current queues in tagset before setting onunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functionshold set->tag_list_lock mutex, which makes sense as we do not wantqueues to be added or deleted in the process. This used to work fineuntil commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset")made the nvme driver quiesce tagset instead of quiscing individualqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues inset->tag_list while holding set->tag_list_lock also.This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53The top stacktrace is showing nvme_timeout() called to handle nvmecommand timeout. timeout handler is trying to disable the controller andas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq notto call queue callback handlers. The thread is stuck waiting forset->tag_list_lock as it tries to walk the queues in set->tag_list.The lock is held by the second thread in the bottom stack which iswaiting for one of queues to be frozen. The queue usage counter willdrop to zero after nvme_timeout() finishes, and this will not happenbecause the thread will wait for this mutex forever.Given that [un]quiescing queue is an operation that does not need tosleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of takingset->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCUsafe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list)in blk_mq_del_queue_tag_set() because we can not re-initialize it whilethe list is being traversed under RCU. The deleted queue will not beadded/deleted to/from a tagset and it will be freed in blk_free_queue()after the end of RCU grace period.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: Discard stale CPU state when handling SME trapsThe logic for handling SME traps manipulates saved FPSIMD/SVE/SME stateincorrectly, and a race with preemption can result in a task havingTIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SME traps enabled). This can result in warnings fromdo_sme_acc() where SME traps are not expected while TIF_SME is set:| /* With TIF_SME userspace shouldn't generate any traps */| if (test_and_set_thread_flag(TIF_SME))| WARN_ON(1);This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")The race can occur when the SME trap handler is preempted before andafter manipulating the saved FPSIMD/SVE/SME state, starting and ending onthe same CPU, e.g.| void do_sme_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SME clear, SME traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| /* With TIF_SME userspace shouldn't generate any traps */| if (test_and_set_thread_flag(TIF_SME))| WARN_ON(1);|| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| unsigned long vq_minus_one =| sve_vq_from_vl(task_get_sme_vl(current)) - 1;| sme_set_vq(vq_minus_one);|| fpsimd_bind_task_to_cpu();| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SME traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.Note: this was originallly posted as [1].[ Rutland: rewrite commit message ]
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check for station first in client probeWhen probing a client, first check if we have it, and thencheck for the channel context, otherwise you can triggerthe warning there easily by probing when the AP isn't evenstarted yet. Since a client existing means the AP is alsooperating, we can then keep the warning.Also simplify the moved code a bit.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation before accessing cgx and lmacwith the addition of new MAC blocks like CN10K RPM and CN10KBRPM_USX, LMACs are noncontiguous and CGX blocks are alsononcontiguous. But during RVU driver initialization, the driveris assuming they are contiguous and trying to accesscgx or lmac with their id which is resulting in kernel panic.This patch fixes the issue by adding proper checks.[ 23.219150] pc : cgx_lmac_read+0x38/0x70[ 23.219154] lr : rvu_program_channels+0x3f0/0x498[ 23.223852] sp : ffff000100d6fc80[ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:000000000000005a[ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:fffffffffff0f000
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:drivers/perf: hisi: Don't migrate perf to the CPU going to teardownThe driver needs to migrate the perf context if the current using CPU goingto teardown. By the time calling the cpuhp::teardown() callback thecpu_online_mask() hasn't updated yet and still includes the CPU going toteardown. In current driver's implementation we may migrate the contextto the teardown CPU and leads to the below calltrace:...[ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008[ 368.113699][ T932] Call trace:[ 368.116834][ T932] __switch_to+0x7c/0xbc[ 368.120924][ T932] __schedule+0x338/0x6f0[ 368.125098][ T932] schedule+0x50/0xe0[ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24[ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc[ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30[ 368.144573][ T932] mutex_lock+0x50/0x60[ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0[ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu][ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650[ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190[ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0[ 368.175099][ T932] kthread+0x108/0x13c[ 368.179012][ T932] ret_from_fork+0x10/0x18...Use function cpumask_any_but() to find one correct active cpu to fixesthis issue.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix deadloop issue on reading trace_pipeSoft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Through the vmcore, I found it's because in tracing_read_pipe(),ring_buffer_empty_cpu() found some buffer is not empty but then itcannot read anything due to "rb_num_of_entries() == 0" always true,Then it infinitely loop the procedure due to user buffer not beenfilled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }By some analyzing, I found that when resetting ringbuffer, the 'entries'of its pages are not all cleared (see rb_reset_cpu()). Then when reducingthe ringbuffer, and if some reduced pages exist dirty 'entries' data, theywill be added into 'cpu_buffer->overrun' (see rb_remove_pages()), whichcause wrong 'overrun' count and eventually cause the deadloop issue.To fix it, we need to clear every pages in rb_reset_cpu().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: Fix __bch_btree_node_alloc to make the failure behavior consistentIn some specific situations, the return value of __bch_btree_node_allocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.Fix it by initializing the return value in __bch_btree_node_alloc.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
containerd > 0-0 (version in image is 1.7.27-1.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: Log an error when close_all_cached_dirs failsUnder low-memory conditions, close_all_cached_dirs() can't move thedentries to a separate list to dput() them once the locks are dropped.This will result in a "Dentry still in use" error, so add an errormessage that makes it clear this is what happened:[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries[ 495.281595] ------------[ cut here ]------------[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs][ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0Also, bail out of looping through all tcons as soon as a singleallocation fails, since we're already in trouble, and kmalloc() attemptsfor subseqeuent tcons are likely to fail just like the first one did.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix validation of VF state in get resourcesVF state I40E_VF_STATE_ACTIVE is not the only state in whichVF is actually active so it should not be used to determineif a VF is allowed to obtain resources.Use I40E_VF_STATE_RESOURCES_LOADED that is set only ini40e_vc_get_vf_resources_msg() and cleared during reset.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Forbid FDB status change while nexthop is in a groupThe kernel forbids the creation of non-FDB nexthop groups with FDBnexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.However, as long as no routes are pointing to a non-FDB nexthop group,the kernel allows changing the type of a nexthop from FDB to non-FDB andvice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0This configuration is invalid and can result in a NPD [1] since FDBnexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1Fix by preventing nexthop FDB status change while the nexthop is in agroup: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.[1]BUG: kernel NULL pointer dereference, address: 00000000000003c0[...]Oops: Oops: 0000 [#1] SMPCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:fib_lookup_good_nhc+0x1e/0x80[...]Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before releaseThe fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can beNULL even after EPF initialization. Then it is prudent to check thatthey have non-NULL values before releasing the channels. Add the checksin pci_epf_test_clean_dma_chan().Without the checks, NULL pointer dereferences happen and they can leadto a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20[mani: trimmed the stack trace]
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - request reserved interrupt for virtual functionThe device interrupt vector 3 is an error interrupt forphysical function and a reserved interrupt for virtual function.However, the driver has not registered the reserved interrupt forvirtual function. When allocating interrupts, the number of interruptsis allocated based on powers of two, which includes this interrupt.When the system enables GICv4 and the virtual function passthroughto the virtual machine, releasing the interrupt in the drivertriggers a warning.The WARNING report is:WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4Therefore, register a reserved interrupt for VF and set theIRQF_NO_AUTOEN flag to avoid that warning.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()The ethtool tsconfig Netlink path can trigger a null pointerdereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower()results in generic_hwtstamp_ioctl_lower() being called withkernel_cfg->ifr as NULL.The generic_hwtstamp_ioctl_lower() function does not expecta NULL ifr and dereferences it, leading to a system crash.Fix this by adding a NULL check for kernel_cfg->ifr ingeneric_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Don't overflow during division for dirty trackingIf pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflowto 0 and this triggers divide by 0.In this case the index should just be 0, so reorganize things to divideby shift and avoid hitting any overflows.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq/longhaul: handle NULL policy in longhaul_exitlonghaul_exit() was calling cpufreq_cpu_get(0) without checkingfor a NULL policy pointer. On some systems, this could lead to aNULL dereference and a kernel warning or panic.This patch adds a check using unlikely() and returns early if thepolicy is NULL.Bugzilla: #219962
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Free special fields when update [lru_,]percpu_hash mapsAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missingcalls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause thememory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until themap gets freed.Fix this by calling 'bpf_obj_free_fields()' after'copy_map_value[,_long]()' in 'pcpu_copy_value()'.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flagsWhen a filesystem is being automounted, it needs to preserve theuser-set superblock mount options, such as the "ro" flag.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.
Packages affected:
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
Packages affected:
python311 > 0-0 (version in image is 3.11.13-2.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Rx page leak on multi-buffer framesThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for eachbuffer in the current frame. This function was introduced as part ofhandling multi-buffer XDP support in the ice driver.It works by iterating over the buffers from first_desc up to 1 plus thetotal number of fragments in the frame, cached from before the XDP programwas executed.If the hardware posts a descriptor with a size of 0, the logic used inice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get addedas fragments in ice_add_xdp_frag. Since the buffer isn't counted as afragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don'tcall ice_put_rx_buf().Because we don't call ice_put_rx_buf(), we don't attempt to re-use thepage or free it. This leaves a stale page in the ring, as we don'tincrement next_to_alloc.The ice_reuse_rx_page() assumes that the next_to_alloc has been incrementedproperly, and that it always points to a buffer with a NULL page. Sincethis function doesn't check, it will happily recycle a page over the topof the next_to_alloc buffer, losing track of the old page.Note that this leak only occurs for multi-buffer frames. Theice_put_rx_mbuf() function always handles at least one buffer, so asingle-buffer frame will always get handled correctly. It is not clearprecisely why the hardware hands us descriptors with a size of 0 sometimes,but it happens somewhat regularly with "jumbo frames" used by 9K MTU.To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() onall buffers between first_desc and next_to_clean. Borrow the logic of asimilar function in i40e used for this same purpose. Use the same logicalso in ice_get_pgcnts().Instead of iterating over just the number of fragments, use a loop whichiterates until the current index reaches to the next_to_clean element justpast the current frame. Unlike i40e, the ice_put_rx_mbuf() function doescall ice_put_rx_buf() on the last buffer of the frame indicating the end ofpacket.For non-linear (multi-buffer) frames, we need to take care when adjustingthe pagecnt_bias. An XDP program might release fragments from the tail ofthe frame, in which case that fragment page is already released. Onlyupdate the pagecnt_bias for the first descriptor and fragments stillremaining post-XDP program. Take care to only access the shared info forfragmented buffers, as this avoids a significant cache miss.The xdp_xmit value only needs to be updated if an XDP program is run, andonly once per packet. Drop the xdp_xmit pointer argument fromice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() functiondirectly. This avoids needing to pass the argument and avoids an extrabit-wise OR for each buffer in the frame.Move the increment of the ntc local variable to ensure its updated *before*all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logicrequires the index of the element just after the current frame.Now that we use an index pointer in the ring to identify the packet, we nolonger need to track or cache the number of fragments in the rx_ring.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Harden uplink netdev access against device unbindThe function mlx5_uplink_netdev_get() gets the uplink netdevicepointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice canbe removed and its pointer cleared when unbound from the mlx5_core.ethdriver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Ensure the pointer is valid before use by checking it for NULL. If itis valid, immediately call netdev_hold() to take a reference, andpreventing the netdevice from being freed while it is in use.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0and sctp_ulpevent_make_authkey() returns 0, then the variableai_ev remains zero and the zero will be dereferencedin the sctp_ulpevent_free() function.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix invalid prog->stats access when update_effective_progs failsSyzkaller triggers an invalid memory access issue following faultinjection in update_effective_progs. The issue can be described asfollows:__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog---softirq start---__do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp)---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype])The reason is that fault injection caused update_effective_progs to failand then changed the original prog into dummy_bpf_prog.prog inpurge_effective_progs. Then a softirq came, and accessing the members ofdummy_bpf_prog.prog in the softirq triggers invalid mem access.To fix it, skip updating stats when stats is NULL.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues
Packages affected:
python311 > 0-0 (version in image is 3.11.13-2.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A flaw was found in OpenSSL's handling of the properties argument in certain functions. This vulnerability can allow use-after-free exploitation, which may result in undefined behavior or incorrect property parsing, leading to OpenSSL treating the input as an empty string.
Packages affected:
libkrun1 > 0-0 (version in image is 1.4.10-1.8).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:perf trace: Really free the evsel->priv areaIn 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields inevsel->priv") it only was freeing if strcmp(evsel->tp_format->system,"syscalls") returned zero, while the corresponding initialization ofevsel->priv was being performed if it was _not_ zero, i.e. if the tpsystem wasn't 'syscalls'.Just stop looking for that and free it if evsel->priv was set, whichshould be equivalent.Also use the pre-existing evsel_trace__delete() function.This resolves these leaks, detected with: $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin ================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]#With this we plug all leaks with "perf trace sleep 1".
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-4.143).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Add a upper bound on max_vclockssyzbot reported WARNING in max_vclocks_store.This occurs when the argument max is too large for kcalloc to handle.Extend the guard to guard against values that are too large forkcalloc
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mte: Do not warn if the page is already tagged in copy_highpage()The arm64 copy_highpage() assumes that the destination page is newlyallocated and not MTE-tagged (PG_mte_tagged unset) and warnsaccordingly. However, following commit 060913999d7a ("mm: migrate:support poisoned recover from migrate folio"), folio_mc_copy() is calledbefore __folio_migrate_mapping(). If the latter fails (-EAGAIN), thecopy will be done again to the same destination page. Sincecopy_highpage() already set the PG_mte_tagged flag, this second copywill warn.Replace the WARN_ON_ONCE(page already tagged) in the arm64copy_highpage() with a comment.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Fix a leak in map_user_pages()If get_user_pages_fast() allocates some pages but not as many as wewanted, then the current code leaks those pages. Call put_page() onthe pages before returning.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:clk: Fix memory leak in devm_clk_notifier_register()devm_clk_notifier_register() allocates a devres resource for clknotifier but didn't register that to the device, so the notifier didn'tget unregistered on device detach and the allocated resource was leaked.Fix the issue by registering the resource through devres_add().This issue was found with kmemleak on a Chromebook.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clkWhen the best clk is searched, we iterate over all possible clk.If we find a better match, the previous one, if any, needs to be freed.If a better match has already been found, we still need to free the newone, otherwise it leaks.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()which can automatically release the related memory when the deviceor driver is removed or unloaded to avoid potential memory leak.In this case, iounmap(anatop_base) in line 427,433 are removedas manual release is not required.Besides, referring to clk-imx8mq.c, check the return code ofof_clk_add_hw_provider, if it returns negtive, print error infoand unregister hws, which makes the program more robust.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objectsIf a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`objects while evaluating the AMD LPS0 _DSM, there will be a memoryleak. Explicitly guard against this.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probeSmatch reports:drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.timer_baseaddr may have the problem of not being released after use,I replaced it with the devm_of_iomap() function and added the clk_put()function to cleanup the "clk_ce" and "clk_cs".
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knodeWhen u32_replace_hw_knode fails, we need to undo the tcf_bind_filteroperation done at u32_set_parms.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.
Packages affected:
iproute2 > 0-0 (version in image is 6.3-4.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error pathsWhen processing mount options, efivarfs allocates efivarfs_fs_info (sfi)early in fs_context initialization. However, sfi is associated with thesuperblock and typically freed when the superblock is destroyed. If thefs_context is released (final put) before fill_super is called-such ason error paths or during reconfiguration-the sfi structure would leak,as ownership never transfers to the superblock.Implement the .free callback in efivarfs_context_ops to ensure anyallocated sfi is properly freed if the fs_context is torn down beforefill_super, preventing this memory leak.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: increase scan_ies_len for S1GCurrently the S1G capability element is not taken into accountfor the scan_ies_len, which leads to a buffer length validationfailure in ieee80211_prep_hw_scan() and subsequent WARN in__ieee80211_start_scan(). This prevents hw scanning from functioning.To fix ensure we accommodate for the S1G capability length.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add max boundary check for VF filtersThere is no check for max filters that VF can request. Add it.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_IDPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zerounique ID.```Each Unit and Terminal within the video function is assigned a uniqueidentification number, the Unit ID (UID) or Terminal ID (TID), contained inthe bUnitID or bTerminalID field of the descriptor. The value 0x00 isreserved for undefined ID,```If we add a new entity with id 0 or a duplicated ID, it will be markedas UVC_INVALID_ENTITY_ID.In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Requireentities to have a non-zero unique ID"), we ignored all the invalid units,this broke a lot of non-compatible cameras. Hopefully we are more luckythis time.This also prevents some syzkaller reproducers from triggering warnings dueto a chain of entities referring to themselves. In one particular case, anOutput Unit is connected to an Input Unit, both with the same ID of 1. Butwhen looking up for the source ID of the Output Unit, that same entity isfound instead of the input entity, which leads to such warnings.In another case, a backward chain was considered finished as the source IDwas 0. Later on, that entity was found, but its pads were not valid.Here is a sample stack trace for one of those cases.[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd[ 20.830206] usb 1-1: Using ep0 maxpacket: 8[ 20.833501] usb 1-1: config 0 descriptor??[ 21.038518] usb 1-1: string descriptor 0 read error: -71[ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201)[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized![ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized![ 21.042218] ------------[ cut here ]------------[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0[ 21.043195] Modules linked in:[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 21.044639] Workqueue: usb_hub_wq hub_event[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0[ 21.051136] PKRU: 55555554[ 21.051331] Call Trace:[ 21.051480] [ 21.051611] ? __warn+0xc4/0x210[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0[ 21.052252] ? report_bug+0x11b/0x1a0[ 21.052540] ? trace_hardirqs_on+0x31/0x40[ 21.052901] ? handle_bug+0x3d/0x70[ 21.053197] ? exc_invalid_op+0x1a/0x50[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20[ 21.053924] ? media_create_pad_link+0x91/0x2e0[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0[ 21.054834] ? media_create_pad_link+0x91/0x2e0[ 21.055131] ? _raw_spin_unlock+0x1e/0x40[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210[ 21.055837] uvc_mc_register_entities+0x358/0x400[ 21.056144] uvc_register_chains+0x1---truncated---
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:vfs: Don't leak disconnected dentries on umountWhen user calls open_by_handle_at() on some inode that is not cached, wewill create disconnected dentry for it. If such dentry is a directory,exportfs_decode_fh_raw() will then try to connect this dentry to thedentry tree through reconnect_path(). It may happen for various reasons(such as corrupted fs or race with rename) that the call tolookup_one_unlocked() in reconnect_one() will fail to find the dentry weare trying to reconnect and instead create a new dentry under theparent. Now this dentry will not be marked as disconnected although theparent still may well be disconnected (at least in case thisinconsistency happened because the fs is corrupted and .. doesn't pointto the real parent directory). This creates inconsistency indisconnected flags but AFAICS it was mostly harmless. At least untilcommit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")which removed adding of most disconnected dentries to sb->s_anon list.Thus after this commit cleanup of disconnected dentries implicitelyrelies on the fact that dput() will immediately reclaim such dentries.However when some leaf dentry isn't marked as disconnected, as in thescenario described above, the reclaim doesn't happen and the dentriesare "leaked". Memory reclaim can eventually reclaim them but otherwisethey stay in memory and if umount comes first, we hit infamous "Busyinodes after unmount" bug. Make sure all dentries created under adisconnected parent are marked as disconnected as well.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.
Packages affected:
libpython3_11-1_0 < 3.11.14-1.1 (version in image is 3.11.13-2.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
Packages affected:
gettext-runtime > 0-0 (version in image is 0.21.1-6.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: tmp is a temporary file and directory creator for node.js. In versions 0.2.3 and below, tmp is vulnerable to an arbitrary temporary file / directory write via symbolic link dir parameter. This is fixed in version 0.2.4.
Packages affected:
cockpit-bridge > 0-0 (version in image is 309-7.2).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix refcount underflow in error pathFix a refcount underflow problem reported by syzbot that can happenwhen a system is running out of memory. If xp_alloc_tx_descs() fails,and it can only fail due to not having enough memory, then the errorpath is triggered. In this error path, the refcount of the pool isdecremented as it has incremented before. However, the reference tothe pool in the socket was not nulled. This means that when the socketis closed later, the socket teardown logic will think that there is apool attached to the socket and try to decrease the refcount again,leading to a refcount underflow.I chose this fix as it involved adding just a single line. Anotheroption would have been to move xp_get_pool() and the assignment ofxs->pool to after the if-statement and using xs_umem->pool instead ofxs->pool in the whole if-statement resulting in somewhat simpler code,but this would have led to much more churn in the code base perhapsmaking it harder to backport.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-4.143).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-4.143).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.
Packages affected:
cockpit-bridge > 0-0 (version in image is 309-7.2).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Packages affected:
libpython3_11-1_0 < 3.11.14-1.1 (version in image is 3.11.13-2.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject unhashed sockets in bpf_sk_assignThe semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk)That is, the sk is not consumed by bpf_sk_assign. The functiontherefore needs to make sure that sk lives long enough to beconsumed from __inet_lookup_skb. The path through the stack for aTCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sockThe existing helper takes advantage of the fact that everythinghappens in the same RCU critical section: for sockets withSOCK_RCU_FREE set bpf_sk_assign never takes a reference.skb_steal_sock then checks SOCK_RCU_FREE again and does sock_putif necessary.This approach assumes that SOCK_RCU_FREE is never set on a skbetween bpf_sk_assign and skb_steal_sock, but this invariant isviolated by unhashed UDP sockets. A new UDP socket is createdin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is onlyadded in udp_lib_get_port() which happens when a socket is bound.When bpf_sk_assign was added it wasn't possible to access unhashedUDP sockets from BPF, so this wasn't a problem. This changedin commit 0c48eefae712 ("sock_map: Lift socket state restrictionfor datagram sockets"), but the helper wasn't adjusted accordingly.The following sequence of events will therefore lead to a refcountleak:1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount.3. bind() or connect() the socket, setting SOCK_RCU_FREE.4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE.5. tcp_v4_rcv() skips sock_put().Fix the problem by rejecting unhashed sockets in bpf_sk_assign().This matches the behaviour of __inet_lookup_skb which is ultimatelythe goal of bpf_sk_assign().
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function'unregister_nvdimm_pmu'.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") theperf_sample_event_took() function was added to report time spent inoverflow interrupts. If the interrupt takes too long, the perf frameworkwill lower the sysctl_perf_event_sample_rate and max_samples_per_tick.When hwc->interrupts is larger than max_samples_per_tick, thehwc->interrupts will be set to MAX_INTERRUPTS, and events will bethrottled within the __perf_event_account_interrupt() function.However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update thePERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()function to avoid throttling. When the perf framework unthrottled the eventin the timer interrupt handler, it triggers riscv_pmu_start() functionand causes a WARN_ON_ONCE() warning, as shown below: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e Modules linked in: CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1 Hardware name: SiFive (DT) epc : riscv_pmu_start+0x7c/0x8e ra : riscv_pmu_start+0x28/0x8e epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0 gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0 t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720 s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000 a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030 s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00 s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000 s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340 s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796 t5 : 0000000700000000 t6 : ffffaf8005269870 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [] riscv_pmu_start+0x7c/0x8e [] perf_adjust_freq_unthr_context+0x15e/0x174 [] perf_event_task_tick+0x88/0x9c [] scheduler_tick+0xfe/0x27c [] update_process_times+0x9a/0xba [] tick_sched_handle+0x32/0x66 [] tick_sched_timer+0x64/0xb0 [] __hrtimer_run_queues+0x156/0x2f4 [] hrtimer_interrupt+0xe2/0x1fe [] riscv_timer_interrupt+0x38/0x42 [] handle_percpu_devid_irq+0x90/0x1d2 [] generic_handle_domain_irq+0x28/0x36After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,they don't call *_pmu_stop() to update with PERF_HES_STOPPED flagafter perf_event_overflow() function nor do they add PERF_HES_STOPPEDflag checking in *_pmu_start() which don't cause this warning.Thus, it's recommended to remove this unnecessary check inriscv_pmu_start() function to prevent this warning.
Packages affected:
kernel-default < 6.4.0-36.1 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Prevent access to vCPU events before initAnother day, another syzkaller bug. KVM erroneously allows userspace topend vCPU events for a vCPU that hasn't been initialized yet, leading toKVM interpreting a bunch of uninitialized garbage for routing /injecting the exception.In one case the injection code and the hyp disagree on whether the vCPUhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)Reject the ioctls outright as no sane VMM would call these beforeKVM_ARM_VCPU_INIT anyway. Even if it did the exception would've beenthrown away by the eventual reset of the vCPU's state.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.
Packages affected:
kernel-default > 0-0 (version in image is 6.4.0-35.1).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).
Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.
Packages affected:
elfutils > 0-0 (version in image is 0.189-4.143).
SL-Micro-release == 6.0 (version in image is 6.0-25.51).