Description: PackageKit is a a D-Bus abstraction layer that allows the user to manage packages in a secure way using a cross-distro, cross-architecture API. PackageKit between and including versions 1.0.2 and 1.3.4 is vulnerable to a time-of-check time-of-use (TOCTOU) race condition on transaction flags that allows unprivileged users to install packages as root and thus leads to a local privilege escalation. This is patched in version 1.3.5.A local unprivileged user can install arbitrary RPM packages as root, including executing RPM scriptlets, without authentication. The vulnerability is a TOCTOU race condition on `transaction->cached_transaction_flags` combined with a silent state-machine guard that discards illegal backward transitions while leaving corrupted flags in place. Three bugs exist in `src/pk-transaction.c`:1. Unconditional flag overwrite (line 4036): `InstallFiles()` writes caller-supplied flags to `transaction->cached_transaction_flags` without checking whether the transaction has already been authorized/started. A second call blindly overwrites the flags even while the transaction is RUNNING.2. Silent state-transition rejection (lines 873-882): `pk_transaction_set_state()` silently discards backward state transitions (e.g. `RUNNING` -> `WAITING_FOR_AUTH`) but the flag overwrite at step 1 already happened. The transaction continues running with corrupted flags.3. Late flag read at execution time (lines 2273-2277): The scheduler's idle callback reads cached_transaction_flags at dispatch time, not at authorization time. If flags were overwritten between authorization and execution, the backend sees the attacker's flags.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
PackageKit < 1.2.8-160000.4.1 (version in image is 1.2.8-160000.3.1).
Description: Buffer Overflow vulnerability in giflib v.5.2.2 allows a remote attacker to cause a denial of service via the EGifGCBToExtension overwriting an existing Graphic Control Extension block without validating its allocated size.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libgif7 > 0-0 (version in image is 5.2.2-160000.2.2).
Description: A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libtiff6 > 0-0 (version in image is 4.7.1-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xen/privcmd: restrict usage in unprivileged domUThe Xen privcmd driver allows to issue arbitrary hypercalls fromuser space processes. This is normally no problem, as access isusually limited to root and the hypervisor will deny any hypercallsaffecting other domains.In case the guest is booted using secure boot, however, the privcmddriver would be enabling a root user process to modify e.g. kernelmemory contents, thus breaking the secure boot feature.The only known case where an unprivileged domU is really needing touse the privcmd driver is the case when it is acting as the devicemodel for another guest. In this case all hypercalls issued via theprivcmd driver will target that other guest.Fortunately the privcmd driver can already be locked down to allowonly hypercalls targeting a specific domain, but this mode can beactivated from user land only today.The target domain can be obtained from Xenstore, so when not runningin dom0 restrict the privcmd driver to that target domain from thebeginning, resolving the potential problem of breaking secure boot.This is XSA-482---V2:- defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich)- wait in open() if target domain isn't known yet- issue message in case no target domain found (Jan Beulich)
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: Use-after-free (UAF) was possible in the `lzma.LZMADecompressor`, `bz2.BZ2Decompressor`, and `gzip.GzipFile` when a memory allocation fails with a `MemoryError` and the decompression instance is re-used. This scenario can be triggered if the process is under memory pressure. The fix cleans up the dangling pointer in this specific error condition.The vulnerability is only present if the program re-uses decompressor instances across multiple decompression calls even after a `MemoryError` is raised during decompression. Using the helper functions to one-shot decompress data such as `lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, and `zlib.decompress()` are not affected as a new decompressor instance is used per call. If the decompressor instance is not re-used after an error condition, this usage is similarly not vulnerable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: sync_linked_regs() must preserve subreg_defRange propagation must not affect subreg_def marks, otherwise thefollowing example is rewritten by verifier incorrectly whenBPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit(or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half).The following happens w/o this patch:- r0 is marked as not a subreg at (0);- w1 is marked as subreg at (2);- w1 subreg_def is overridden at (3) by copy_register_state();- w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set;- because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r));- this random value is read at (5).
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/umad: Reject negative data_len in ib_umad_writeib_umad_write computes data_len from user-controlled count and theMAD header sizes. With a mismatched user MAD header size and RMPPheader length, data_len can become negative and reach ib_create_send_mad().This can make the padding calculation exceed the segment size and triggeran out-of-bounds memset in alloc_send_rmpp_list().Add an explicit check to reject negative data_len before creating thesend buffer.KASAN splat:[ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0[ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102[ 211.365867] ib_create_send_mad+0xa01/0x11b0[ 211.365887] ib_umad_write+0x853/0x1c80
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: algif_aead - Revert to operating out-of-placeThis mostly reverts commit 72548b093ee3 except for the copying ofthe associated data.There is no benefit in operating in-place in algif_aead since thesource and destination come from different mappings. Get rid ofall the complexity added for in-place operation and just copy theAD directly.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.29.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffersmc_rx_splice() allocates one smc_spd_priv per pipe_buffer and storesthe pointer in pipe_buffer.private. The pipe_buf_operations for thesebuffers used .get = generic_pipe_buf_get, which only increments the pagereference count when tee(2) duplicates a pipe buffer. The smc_spd_privpointer itself was not handled, so after tee() both the original and thecloned pipe_buffer share the same smc_spd_priv *.When both pipes are subsequently released, smc_rx_pipe_buf_release() iscalled twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), whichthen escalates to a NULL-pointer dereference and kernel panic viasmc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exceptionBeyond the memory-safety problem, duplicating an SMC splice buffer issemantically questionable: smc_rx_update_cons() would advance theconsumer cursor twice for the same data, corrupting receive-windowaccounting. A refcount on smc_spd_priv could fix the double-free, butthe cursor-accounting issue would still need to be addressed separately.The .get callback is invoked by both tee(2) and splice_pipe_to_pipe()for partial transfers; both will now return -EFAULT. Users who needto duplicate SMC socket data must use a copy-based read path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Require sys_futex_requeue() to have identical flagsNicholas reported that his LLM found it was possible to create a UaFwhen sys_futex_requeue() is used with different flags. The initialmotivation for allowing different flags was the variable sized futex,but since that hasn't been merged (yet), simply mandate the flags areidentical, as is the case for the old style sys_futex() requeueoperations.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix cached_dev.sb_bio use-after-free and crashIn our production environment, we have received multiple crash reportsregarding libceph, which have caught our attention:```[6888366.280350] Call Trace:[6888366.280452] blk_update_request+0x14e/0x370[6888366.280561] blk_mq_end_request+0x1a/0x130[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd][6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd][6888366.280903] __complete_request+0x22/0x70 [libceph][6888366.281032] osd_dispatch+0x15e/0xb40 [libceph][6888366.281164] ? inet_recvmsg+0x5b/0xd0[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph][6888366.281405] ceph_con_process_message+0x79/0x140 [libceph][6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph][6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]```After analyzing the coredump file, we found that the address ofdc->sb_bio has been freed. We know that cached_dev is only freed when itis stopped.Since sb_bio is a part of struct cached_dev, rather than an alloc everytime. If the device is stopped while writing to the superblock, thereleased address will be accessed at endio.This patch hopes to wait for sb_write to complete in cached_dev_free.It should be noted that we analyzed the cause of the problem, then tellall details to the QWEN and adopted the modifications it made.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (powerz) Fix use-after-free on USB disconnectAfter powerz_disconnect() frees the URB and releases the mutex, asubsequent powerz_read() call can acquire the mutex and callpowerz_read_data(), which dereferences the freed URB pointer.Fix by: - Setting priv->urb to NULL in powerz_disconnect() so that powerz_read_data() can detect the disconnected state. - Adding a !priv->urb check at the start of powerz_read_data() to return -ENODEV on a disconnected device. - Moving usb_set_intfdata() before hwmon registration so the disconnect handler can always find the priv pointer.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: fix use-after-free in encoder release pathThe fops_vcodec_release() function frees the context structure (ctx)without first cancelling any pending or running work in ctx->encode_work.This creates a race window where the workqueue handler (mtk_venc_worker)may still be accessing the context memory after it has been freed.Race condition: CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // waits for m2m job "done" mtk_venc_worker() v4l2_m2m_job_finish() // m2m job "done" // BUT worker still running! // post-job_finish access: other ctx dereferences // UAF if ctx already freed // returns (job "done") kfree(ctx) // ctx freedRoot cause: The v4l2_m2m_ctx_release() only waits for the m2m joblifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle.After v4l2_m2m_job_finish() is called, the m2m framework considersthe job complete and v4l2_m2m_ctx_release() returns, but the workerfunction continues executing and may still access ctx.The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work)The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctxfields even after calling v4l2_m2m_job_finish().This vulnerability was confirmed with KASAN by running an instrumentedtest module that widens the post-job_finish race window. KASAN detected: BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx).This ensures the workqueue handler is both cancelled (if pending) andsynchronized (waits for any running handler to complete) before thecontext is freed.Placement rationale: The fix is placed after v4l2_ctrl_handler_free()and before list_del_init(&ctx->list). At this point, all m2m operationsare done (v4l2_m2m_ctx_release() has returned), and we need to ensurethe workqueue is synchronized before removing ctx from the list andfreeing it.Note: The open error path does NOT need cancel_work_sync() becauseINIT_WORK() only initializes the work structure - it does not scheduleit. Work is only scheduled later during device_run() operations.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRYfilemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,as documented in mm/filemap.c: "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."When this happens, a concurrent munmap() can call remove_vma() and freethe vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() thenbecomes a dangling pointer, and the subsequent trace_ocfs2_fault() calldereferences it -- a use-after-free.Fix this by saving ip_blkno as a plain integer before callingfilemap_fault(), and removing vma from the trace event. Sinceip_blkno is copied by value before the lock can be dropped, itremains valid regardless of what happens to the vma or inodeafterward.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Limit PTP to a single pageCommit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256playback streams, but the additional pages are not used by the cardcorrectly. The CT20K2 hardware already has multiple VMEM_PTPALregisters, but using them separately would require refactoring theentire virtual memory allocation logic.ct_vm_map() always uses PTEs in vm->ptp[0].area regardless ofCT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). Whenaggregate memory allocations exceed this limit, ct_vm_map() tries toaccess beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7eRevert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_countremain unchanged.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in binutils. A heap-buffer-overflow vulnerability exists when processing a specially crafted XCOFF (Extended Common Object File Format) object file during linking. A local attacker could trick a user into processing this malicious file, which could lead to arbitrary code execution, allowing the attacker to run unauthorized commands, or cause a denial of service, making the system unavailable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignmentsmb2_get_ea() applies 4-byte alignment padding via memset() afterwriting each EA entry. The bounds check on buf_free_len is performedbefore the value memcpy, but the alignment memset fires unconditionallyafterward with no check on remaining space.When the EA value exactly fills the remaining buffer (buf_free_len == 0after value subtraction), the alignment memset writes 1-3 NUL bytespast the buf_free_len boundary. In compound requests where the responsebuffer is shared across commands, the first command (e.g., READ) canconsume most of the buffer, leaving a tight remainder for the QUERY_INFOEA response. The alignment memset then overwrites past the physicalkvmalloc allocation into adjacent kernel heap memory.Add a bounds check before the alignment memset to ensure buf_free_lencan accommodate the padding bytes.This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fixpotencial OOB in get_file_all_info() for compound requests") andcommit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compoundrequests"), both of which added bounds checks before unconditionalwrites in QUERY_INFO response handlers.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm: call ->free_folio() directly in folio_unmap_invalidate()We can only call filemap_free_folio() if we have a reference to (or hold alock on) the mapping. Otherwise, we've already removed the folio from themapping so it no longer pins the mapping and the mapping can be removed,causing a use-after-free when accessing mapping->a_ops.Follow the same pattern as __remove_mapping() and load the free_foliofunction pointer before dropping the lock on the mapping. That lets usmake filemap_free_folio() static as this was the only caller outsidefilemap.c.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: require 3 sub-authorities before reading sub_auth[2]parse_dacl() compares each ACE SID against sid_unix_NFS_mode and onmatch reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode isthe prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() comparesonly min(num_subauth, 2) sub-authorities so a client SID withnum_subauth = 2 and sub_auth = {88, 3} will match.If num_subauth = 2 and the ACE is placed at the very end of the securitydescriptor, sub_auth[2] will be 4 bytes past end_of_acl. Theout-of-band bytes will then be masked to the low 9 bits and applied asthe file's POSIX mode, probably not something that is good to havehappen.Fix this up by forcing the SID to actually carry a third sub-authoritybefore reading it at all.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: The NPM package `micromatch` prior to 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in `micromatch.braces()` in `index.js` because the pattern `.*` will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persists. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching. This issue was fixed in version 4.0.8.
Packages affected:
cockpit > 0-0 (version in image is 354-160000.3.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313-setuptools > 0-0 (version in image is 78.1.1-160000.2.2).
Description: Rack is a modular Ruby web server interface. Prior to versions 2.2.22, 3.1.20, and 3.2.5, `Rack::Directory`'s path check used a string prefix match on the expanded path. A request like `/../root_example/` can escape the configured root if the target path starts with the root string, allowing directory listing outside the intended root. Versions 2.2.22, 3.1.20, and 3.2.5 fix the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: @isaacs/brace-expansion is a hybrid CJS/ESM TypeScript fork of brace-expansion. Prior to version 5.0.1, @isaacs/brace-expansion is vulnerable to a denial of service (DoS) issue caused by unbounded brace range expansion. When an attacker provides a pattern containing repeated numeric brace ranges, the library attempts to eagerly generate every possible combination synchronously. Because the expansion grows exponentially, even a small input can consume excessive CPU and memory and may crash the Node.js process. This issue has been patched in version 5.0.1.
Packages affected:
cockpit-packages > 0-0 (version in image is 4-160000.1.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: time provides date and time handling in Rust. From 0.3.6 to before 0.3.47, when user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario. A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
gdk-pixbuf-loader-rsvg < 2.60.2-160000.2.1 (version in image is 2.60.2-160000.1.1).
Description: minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.4, nested `*()` extglobs produce regexps with nested unbounded quantifiers (e.g. `(?:(?:a|b)*)*`), which exhibit catastrophic backtracking in V8. With a 12-byte pattern `*(*(*(a|b)))` and an 18-byte non-matching input, `minimatch()` stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default `minimatch()` API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects `+()` extglobs equally. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.4 fix the issue.
Packages affected:
cockpit > 0-0 (version in image is 354-160000.3.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix possible deadlock between unlink and dio_end_io_writeocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.This creates an ABBA lock ordering violation on lock classesocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] andocfs2_file_ip_alloc_sem_key.Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem):ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock BLock Chain #1 (ip_alloc_sem -> orphan dir inode_lock):ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock ADeadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)Since ip_alloc_sem is to protect allocation changes, which is unrelatedwith operations in ocfs2_del_inode_from_orphan. So moveocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix integer underflow in chain modeThe jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax;where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax isBUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit()decides to invoke jumbo_frm() based on skb->len (total length includingpage fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc);When a packet has a small linear portion (nopaged_len <= bmax) but alarge total length due to page fragments (skb->len > bmax), thesubtraction wraps as an unsigned integer, producing a huge len value(~0xFFFFxxxx). This causes the while (len != 0) loop to executehundreds of thousands of iterations, passing skb->data + bmax * ipointers far beyond the skb buffer to dma_map_single(). On IOMMU-lessSoCs (the typical deployment for stmmac), this maps arbitrary kernelmemory to the DMA engine, constituting a kernel memory disclosure andpotential memory corruption from hardware.Fix this by introducing a buf_len local variable clamped tomin(nopaged_len, bmax). Computing len = nopaged_len - buf_len is thenalways safe: it is zero when the linear portion fits within a singledescriptor, causing the while (len != 0) loop to be skipped naturally,and the fragment loop in stmmac_xmit() handles page fragments afterward.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSGThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrementsbc_ackers on every inbound group ACK, even when the same member hasalready acknowledged the current broadcast round.Because bc_ackers is a u16, a duplicate ACK received after the lastlegitimate ACK wraps the counter to 65535. Once wrapped,tipc_group_bc_cong() keeps reporting congestion and later groupbroadcasts on the affected socket stay blocked until the group isrecreated.Fix this by ignoring duplicate or stale ACKs before touching bc_acked orbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent andprevents the underflow path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Active Storage allows users to attach cloud and local files in Rails applications. Prior to versions 8.1.2.1, 8.0.4.1, and 7.2.3.1, when serving files through Active Storage's proxy delivery mode, the proxy controller loads the entire requested byte range into memory before sending it. A request with a large or unbounded Range header (e.g. `bytes=0-`) could cause the server to allocate memory proportional to the file size, possibly resulting in a DoS vulnerability through memory exhaustion. Versions 8.1.2.1, 8.0.4.1, and 7.2.3.1 contain a patch.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: Active Support is a toolkit of support libraries and Ruby core extensions extracted from the Rails framework. Prior to versions 8.1.2.1, 8.0.4.1, and 7.2.3.1, Active Support number helpers accept strings containing scientific notation (e.g. `1e10000`), which `BigDecimal` expands into extremely large decimal representations. This can cause excessive memory allocation and CPU consumption when the expanded number is formatted, possibly resulting in a DoS vulnerability. Versions 8.1.2.1, 8.0.4.1, and 7.2.3.1 contain a patch.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: Active Storage allows users to attach cloud and local files in Rails applications. Prior to versions 8.1.2.1, 8.0.4.1, and 7.2.3.1, Active Storage's `DiskService#delete_prefixed` passes blob keys directly to `Dir.glob` without escaping glob metacharacters. If a blob key contains attacker-controlled input or custom-generated keys with glob metacharacters, it may be possible to delete unintended files from the storage directory. Versions 8.1.2.1, 8.0.4.1, and 7.2.3.1 contain a patch.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to version 0.28.1, insufficient validation of Git URL fragment subdir components may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem. The issue has been fixed in version v0.28.1 The issue affects only builds that use Git URLs with a subpath component. As a workaround, avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
podman > 0-0 (version in image is 5.4.2-160000.4.1).
Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
podman > 0-0 (version in image is 5.4.2-160000.4.1).
Description: The iconv() function in the GNU C Library versions 2.43 and earlier may crash due to an assertion failure when converting inputs from the IBM1390 or IBM1399 character sets, which may be used to remotely crash an application.This vulnerability can be trivially mitigated by removing the IBM1390 and IBM1399 character sets from systems that do not need them.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glibc > 0-0 (version in image is 2.40-160000.4.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_eui64: reject invalid MAC header for all packets`eui64_mt6()` derives a modified EUI-64 from the Ethernet source addressand compares it with the low 64 bits of the IPv6 source address.The existing guard only rejects an invalid MAC header when`par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()`can still reach `eth_hdr(skb)` even when the MAC header is not valid.Fix this by removing the `par->fragoff != 0` condition so that packetswith an invalid MAC header are rejected before accessing `eth_hdr(skb)`.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: XZ Utils provide a general-purpose data-compression library plus command-line tools. Prior to version 5.8.3, if lzma_index_decoder() was used to decode an Index that contained no Records, the resulting lzma_index was left in a state where where a subsequent lzma_index_append() would allocate too little memory, and a buffer overflow would occur. This issue has been patched in version 5.8.3.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
liblzma5 > 0-0 (version in image is 5.8.1-160000.2.2).
Description: In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
sudo < 1.9.17p1-160000.3.1 (version in image is 1.9.17p1-160000.2.2).
Description: A security vulnerability has been detected in libssh2 up to 1.11.1. The impacted element is the function userauth_password of the file src/userauth.c. Such manipulation of the argument username_len/password_len leads to integer overflow. The attack may be launched remotely. The name of the patch is 256d04b60d80bf1190e96b0ad1e91b2174d744b1. A patch should be applied to remediate this issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh2-1 > 0-0 (version in image is 1.11.1-160000.3.2).
Description: In rsync 3.0.1 through 3.4.1, receive_xattr relies on an untrusted length value during a qsort call, leading to a receiver use-after-free. The victim must run rsync with -X (aka --xattrs). On Linux, many (but not all) common configurations are vulnerable. Non-Linux platforms are more widely vulnerable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
rsync > 0-0 (version in image is 3.4.1-160000.2.3).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB reads parsing symlink error responseWhen a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()returns success without any length validation, leaving the symlinkparsers as the only defense against an untrusted server.symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p->ErrorDataLength at offset0. When the server-controlled ErrorDataLength advances p to within 1-7bytes of end, the next iteration will read past it. When the matchingcontext is found, sym->SymLinkErrorTag is read at offset 4 fromp->ErrorContextData with no check that the symlink header itself fits.smb2_parse_symlink_response() then bounds-checks the substitute nameusing SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer fromiov_base. That value is computed as sizeof(smb2_err_rsp) +sizeof(smb2_symlink_err_rsp), which is correct only whenErrorContextCount == 0.With at least one error context the symlink data sits 8 bytes deeper,and each skipped non-matching context shifts it further by 8 +ALIGN(ErrorDataLength, 8). The check is too short, allowing thesubstitute name read to run past iov_len. The out-of-bound heap bytesare UTF-16-decoded into the symlink target and returned to userspace viareadlink(2).Fix this all up by making the loops test require the full context headerto fit, rejecting sym if its header runs past end, and bound thesubstitute name against the actual position of sym->PathBuffer ratherthan a fixed offset.Because sub_offs and sub_len are 16bits, the pointer math will notoverflow here with the new greater-than.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix off-by-8 bounds check in check_wsl_eas()The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EAname and value, but ea_data sits at offset sizeof(structsmb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp()later reads ea->ea_data[0..nlen-1] and the value bytes follow atea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1+ vlen. Isn't pointer math fun?The earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the8-byte header is in bounds, but since the last EA is placed within 8bytes of the end of the response, the name and value bytes are read pastthe end of iov.Fix this mess all up by using ea->ea_data as the base for the boundscheck.An "untrusted" server can use this to leak up to 8 bytes of kernel heapinto the EA name comparison and influence which WSL xattr the data isinterpreted as.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: validate response sizes in ipc_validate_msg()ipc_validate_msg() computes the expected message size for eachresponse type by adding (or multiplying) attacker-controlled fieldsfrom the daemon response to a fixed struct size in unsigned intarithmetic. Three cases can overflow: KSMBD_EVENT_RPC_REQUEST: msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz; KSMBD_EVENT_SHARE_CONFIG_REQUEST: msg_sz = sizeof(struct ksmbd_share_config_response) + resp->payload_sz; KSMBD_EVENT_LOGIN_REQUEST_EXT: msg_sz = sizeof(struct ksmbd_login_response_ext) + resp->ngroups * sizeof(gid_t);resp->payload_sz is __u32 and resp->ngroups is __s32. Each additioncan wrap in unsigned int; the multiplication by sizeof(gid_t) mixessigned and size_t, so a negative ngroups is converted to SIZE_MAXbefore the multiply. A wrapped value of msg_sz that happens toequal entry->msg_sz bypasses the size check on the next line, anddownstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz,kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust theunverified length.Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUESTpaths to detect integer overflow without constraining functionalpayload size; userspace ksmbd-tools grows NDR responses in 4096-bytechunks for calls like NetShareEnumAll, so a hard transport cap isunworkable on the response side. For LOGIN_REQUEST_EXT, rejectresp->ngroups outside the signed [0, NGROUPS_MAX] range up front andreport the error from ipc_validate_msg() so it fires at the IPCboundary; with that bound the subsequent multiplication and additionstay well below UINT_MAX. The now-redundant ngroups check andpr_err in ksmbd_alloc_user() are removed.This is the response-side analogue of aab98e2dbd64 ("ksmbd: fixinteger overflows on 32 bit systems"), which hardened the requestside.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Mitgation of CVE-2026-4519 was incomplete. If the URL contained "%action" the mitigation could be bypassed for certain browser types the "webbrowser.open()" API could have commands injected into the underlying shell. See CVE-2026-4519 for details.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix oops due to uninitialised variableFix smb3_init_transform_rq() to initialise buffer to NULL before callingnetfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer itis given. Setting it to NULL means it should start a fresh buffer, but thevalue is currently undefined.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: OpenJPEG is an open-source JPEG 2000 codec. In OpenJPEG from 2.5.1 through 2.5.3, a call to opj_jp2_read_header may lead to OOB heap memory write when the data stream p_stream is too short and p_image is not initialized.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libopenjp2-7 > 0-0 (version in image is 2.5.3-160000.3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sva: invalidate stale IOTLB entries for kernel address spaceIntroduce a new IOMMU interface to flush IOTLB paging cache entries forthe CPU kernel address space. This interface is invoked from the x86architecture code that manages combined user and kernel page tables,specifically before any kernel page table page is freed and reused.This addresses the main issue with vfree() which is a common occurrenceand can be triggered by unprivileged users. While this resolves theprimary problem, it doesn't address some extremely rare case related tomemory unplug of memory that was present as reserved memory at boot, whichcannot be triggered by unprivileged users. The discussion can be found atthe link below.Enable SVA on x86 architecture since the IOMMU can now receivenotification to flush the paging cache before freeing the CPU kernel pagetable pages.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_u32: use skb_header_pointer_careful()skb_header_pointer() does not fully validate negative @offset values.Use skb_header_pointer_careful() instead.GangMin Kim provided a report and a repro fooling u32_classify():BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0net/sched/cls_u32.c:221
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/freeExynos Virtual Display driver performs memory alloc/free operationswithout lock protection, which easily causes concurrency problem.For example, use-after-free can occur in race scenario like this:``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ...```To prevent these vulns, at least in vidi_context, member variables relatedto memory alloc/free should be protected with ctx->lock.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix use-after-free in nf_tables_addchain()nf_tables_addchain() publishes the chain to table->chains vialist_add_tail_rcu() (in nft_chain_add()) before registering hooks.If nf_tables_register_hook() then fails, the error path callsnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()with no RCU grace period in between.This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain.Add synchronize_rcu() between nft_chain_del() and the chain destroyso that all RCU readers -- both dump threads and in-flight packetevaluation -- have finished before the chain is freed.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: Fix race condition in espintcp_close()This issue was discovered during a code audit.After cancel_work_sync() is called from espintcp_close(),espintcp_tx_work() can still be scheduled from paths such asthe Delayed ACK handler or ksoftirqd.As a result, the espintcp_tx_work() worker may dereference afreed espintcp ctx or sk.The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work);To prevent this race condition, cancel_work_sync() isreplaced with disable_work_sync().
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Fix race condition in tls_sw_cancel_work_tx()This issue was discovered during a code audit.After cancel_delayed_work_sync() is called from tls_sk_proto_close(),tx_work_handler() can still be scheduled from paths such as theDelayed ACK handler or ksoftirqd.As a result, the tx_work_handler() worker may dereference a freedTLS object.The following is a simple race scenario: cpu0 cpu1tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0);To prevent this race condition, cancel_delayed_work_sync() isreplaced with disable_delayed_work_sync().
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix refcount bug and potential UAF in perf_mmapSyzkaller reported a refcount_t: addition on 0; use-after-free warningin perf_mmap.The issue is caused by a race condition between a failing mmap() setupand a concurrent mmap() on a dependent event (e.g., using outputredirection).In perf_mmap(), the ring_buffer (rb) is allocated and assigned toevent->rb with the mmap_mutex held. The mutex is then released toperform map_range().If map_range() fails, perf_mmap_close() is called to clean up.However, since the mutex was dropped, another thread attaching tothis event (via inherited events or output redirection) can acquirethe mutex, observe the valid event->rb pointer, and attempt toincrement its reference count. If the cleanup path has alreadydropped the reference count to zero, this results in ause-after-free or refcount saturation warning.Fix this by extending the scope of mmap_mutex to cover themap_range() call. This ensures that the ring buffer initializationand mapping (or cleanup on failure) happens atomically effectively,preventing other threads from accessing a half-initialized ordying ring buffer.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix unprivileged local user can do privileged policy managementAn unprivileged local user can load, replace, and remove profiles byopening the apparmorfs interfaces, via a confused deputy attack, bypassing the opened fd to a privileged process, and getting theprivileged process to write to the interface.This does require a privileged target that can be manipulated to dothe write for the unprivileged process, but once such access isachieved full policy management is possible and all the possibleimplications that implies: removing confinement, DoS of system ortarget applications by denying all execution, by-passing theunprivileged user namespace restriction, to exploiting kernel bugs fora local privilege escalation.The policy management interface can not have its permissions simplychanged from 0666 to 0600 because non-root processes need to be ableto load policy to different policy namespaces.Instead ensure the task writing the interface has privileges thatare a subset of the task that opened the interface. This is alreadydone via policy for confined processes, but unconfined can delegateaccess to the opened fd, by-passing the usual policy check.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: unconditionally bump set->nelems before insertionIn case that the set is full, a new element gets published then removedwithout waiting for the RCU grace period, while RCU reader can bewalking over it already.To address this issue, add the element transaction even if set is full,but toggle the set_full flag to report -ENFILE so the abort path safelyunwinds the set to its previous state.As for element updates, decrement set->nelems to restore it.A simpler fix is to call synchronize_rcu() in the error path.However, with a large batch adding elements to already maxed-out set,this could cause noticeable slowdown of such batches.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labelsIDLETIMER revision 0 rules reuse existing timers by label and always callmod_timer() on timer->timer.If the label was created first by revision 1 with XT_IDLETIMER_ALARM,the object uses alarm timer semantics and timer->timer is never initialized.Reusing that object from revision 0 causes mod_timer() on an uninitializedtimer_list, triggering debugobjects warnings and possible panic whenpanic_on_warn=1.Fix this by rejecting revision 0 rule insertion when an existing timer withthe same label is of ALARM type.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always walk all pending catchall elementsDuring transaction processing we might have more than one catchall element:1 live catchall element and 1 pending element that is coming as part of thenew batch.If the map holding the catchall elements is also going away, itsrequired to toggle all catchall elements and not just the first viablecandidate.Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: release flowtable after rcu grace period on errorCall synchronize_rcu() after unregistering the hooks from error path,since a hook that already refers to this flowtable can be alreadyregistered, exposing this flowtable to packet path and nfnetlink_hookcontrol plane.This error path is rare, it should only happen by reaching the maximumnumber hooks or by failing to set up to hardware offload, just callsynchronize_rcu().There is a check for already used device hooks by different flowtablethat could result in EEXIST at this late stage. The hook parser can beupdated to perform this check earlier to this error path really becomesrarely exercised.Uncovered by KASAN reported as use-after-free from nfnetlink_hook pathwhen dumping hooks.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: cfm: Fix race condition in peer_mep deletionWhen a peer MEP is being deleted, cancel_delayed_work_sync() is calledon ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs insoftirq context under rcu_read_lock (without RTNL) and can re-scheduleccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()returning and kfree_rcu() being called.The following is a simple race scenario: cpu0 cpu1mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mepTo prevent this, cancel_delayed_work_sync() is replaced withdisable_delayed_work_sync() in both peer MEP deletion paths, sothat subsequent queue_delayed_work() calls from br_cfm_frame_rx()are silently rejected.The cc_peer_disable() helper retains cancel_delayed_work_sync()because it is also used for the CC enable/disable toggle path wherethe work must remain re-schedulable.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lockbtintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESETand Intel exception-info retrieval) without holdinghci_req_sync_lock(). This lets it race againsthci_dev_do_close() -> btintel_shutdown_combined(), which also runs__hci_cmd_sync() under the same lock. When both paths manipulatehdev->req_status/req_rsp concurrently, the close path may free theresponse skb first, and the still-running hw_error path hits aslab-use-after-free in kfree_skb().Wrap the whole recovery sequence in hci_req_sync_lock/unlock so itis serialized with every other synchronous HCI command issuer.Below is the data race report and the kasan report: BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined read of hdev->req_rsp at net/bluetooth/hci_sync.c:199 by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254 hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030 write/free by task ioctl/22580: btintel_shutdown_combined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246 hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526 BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix fanout UAF in packet_release() via NETDEV_UP race`packet_release()` has a race window where `NETDEV_UP` can re-register asocket into a fanout group's `arr[]` array. The re-registration is notcleaned up by `fanout_release()`, leaving a dangling pointer in the fanoutarray.`packet_release()` does NOT zero `po->num` in its `bind_lock` section.After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex`still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`that already found the socket in `sklist` can re-register the hook.For fanout sockets, this re-registration calls `__fanout_link(sk, po)`which adds the socket back into `f->arr[]` and increments `f->num_members`,but does NOT increment `f->sk_ref`.The fix sets `po->num` to zero in `packet_release` while `bind_lock` isheld to prevent NETDEV_UP from linking, preventing the race window.This bug was found following an additional audit with Claude Code basedon CVE-2025-38617.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MINThe BPF interpreter's signed 32-bit division and modulo handlers usethe kernel abs() macro on s32 operands. The abs() macro documentation(include/linux/math.h) explicitly states the result is undefined whenthe input is the type minimum. When DST contains S32_MIN (0x80000000),abs((s32)DST) triggers undefined behavior and returns S32_MIN unchangedon arm64/x86. This value is then sign-extended to u64 as0xFFFFFFFF80000000, causing do_div() to compute the wrong result.The verifier's abstract interpretation (scalar32_min_max_sdiv) computesthe mathematically correct result for range tracking, creating averifier/interpreter mismatch that can be exploited for out-of-boundsmap value access.Introduce abs_s32() which handles S32_MIN correctly by casting to u32before negating, avoiding signed overflow entirely. Replace all 8abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers.s32 is the only affected case -- the s64 division/modulo handlers donot use abs().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Make sure to use pmu_ctx->pmu for groupsOliver reported that x86_pmu_del() ended up doing an out-of-bound memory accesswhen group_sched_in() fails and needs to roll back.This *should* be handled by the transaction callbacks, but he found that whenthe group leader is a software event, the transaction handlers of the wrong PMUare used. Despite the move_group case in perf_event_open() and group_sched_in()using pmu_ctx->pmu.Turns out, inherit uses event->pmu to clone the events, effectively undoing themove_group case for all inherited contexts. Fix this by also making inherit usepmu_ctx->pmu, ensuring all inherited counters end up in the same pmu context.Similarly, __perf_event_read() should use equally use pmu_ctx->pmu for thegroup case.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix use-after-free in -EBUSY error path of tls_do_encryptionThe -EBUSY handling in tls_do_encryption(), introduced by commit859054147318 ("net: tls: handle backlogging of crypto requests"), hasa use-after-free due to double cleanup of encrypt_pending and thescatterlist entry.When crypto_aead_encrypt() returns -EBUSY, the request is enqueued tothe cryptd backlog and the async callback tls_encrypt_done() will beinvoked upon completion. That callback unconditionally restores thescatterlist entry (sge->offset, sge->length) and decrementsctx->encrypt_pending. However, if tls_encrypt_async_wait() returns anerror, the synchronous error path in tls_do_encryption() performs thesame cleanup again, double-decrementing encrypt_pending anddouble-restoring the scatterlist.The double-decrement corrupts the encrypt_pending sentinel (initializedto 1), making tls_encrypt_async_wait() permanently skip the wait forpending async callbacks. A subsequent sendmsg can then free thetls_rec via bpf_exec_tx_verdict() while a cryptd callback is stillpending, resulting in a use-after-free when the callback fires on thefreed record.Fix this by skipping the synchronous cleanup when the -EBUSY asyncwait returns an error, since the callback has already handledencrypt_pending and sge restoration.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: make use of smbdirect_socket.recv_io.credits.availableThe logic off managing recv credits by counting posted recv_io andgranted credits is racy.That's because the peer might already consumed a credit,but between receiving the incoming recv at the hardwareand processing the completion in the 'recv_done' functionswe likely have a window where we grant credits, whichdon't really exist.So we better have a decicated counter for theavailable credits, which will be incrementedwhen we posted new recv buffers and drained whenwe grant the credits to the peer.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Clear stale exiting pointer in futex_lock_pi() retry pathFuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSYand stores a refcounted task pointer in 'exiting'.After wait_for_owner_exiting() consumes that reference, the local pointeris never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns adifferent error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting)Fix this by resetting upon retry, essentially aligning it with requeue_pi.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: 6fire: fix use-after-free on disconnectIn usb6fire_chip_abort(), the chip struct is allocated as the card'sprivate data (via snd_card_new with sizeof(struct sfire_chip)). Whensnd_card_free_when_closed() is called and no file handles are open, thecard and embedded chip are freed synchronously. The subsequentchip->card = NULL write then hits freed slab memory.Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953Fix by moving the card lifecycle out of usb6fire_chip_abort() and intousb6fire_chip_disconnect(). The card pointer is saved in a localbefore any teardown, snd_card_disconnect() is called first to preventnew opens, URBs are aborted while chip is still valid, andsnd_card_free_when_closed() is called last so chip is never accessedafter the card may be freed.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:media: em28xx: fix use-after-free in em28xx_v4l2_open()em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock,creating a race with em28xx_v4l2_init()'s error path andem28xx_v4l2_fini(), both of which free the em28xx_v4l2 structand set dev->v4l2 to NULL under dev->lock.This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL.Fix this by moving the mutex_lock() before the dev->v4l2 read andadding a NULL check for dev->v4l2 under the lock.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesseswb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the lastreference, the blkcg can be freed asynchronously (css_free_rwork_fn ->blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences thepointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)** Stack based on commit 66672af7a095 ("Add linux-next specific filesfor 20260410")I am seeing this crash sporadically in Meta fleet across multiple kernelversions. A full reproducer is available at:https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh(The race window is narrow. To make it easily reproducible, inject amsleep(100) between css_put() and blkcg_unpin_online() incgwb_release_workfn(). With that delay and a KASAN-enabled kernel, thereproducer triggers the splat reliably in less than a second.)Fix this by moving blkcg_unpin_online() before css_put(), so thecgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online()accesses it.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Use scratch field in MMIO fragment to hold small write valuesWhen exiting to userspace to service an emulated MMIO write, copy theto-be-written value to a scratch field in the MMIO fragment if the sizeof the data payload is 8 bytes or less, i.e. can fit in a single chunk,instead of pointing the fragment directly at the source value.This fixes a class of use-after-free bugs that occur when the emulatorinitiates a write using an on-stack, local variable as the source, thewrite splits a page boundary, *and* both pages are MMIO pages. BecauseKVM's ABI only allows for physically contiguous MMIO requests, accessesthat split MMIO pages are separated into two fragments, and are sent touserspace one at a time. When KVM attempts to complete userspace MMIO inresponse to KVM_RUN after the first fragment, KVM will detect the secondfragment and generate a second userspace exit, and reference the on-stackvariable.The issue is most visible if the second KVM_RUN is performed by a separatetask, in which case the stack of the initiating task can show up as trulyfreed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================The bug can also be reproduced with a targeted KVM-Unit-Test by hackingKVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. byoverwrite the data value with garbage.Limit the use of the scratch fields to 8-byte or smaller accesses, and tojust writes, as larger accesses and reads are not affected thanks toimplementation details in the emulator, but add a sanity check to ensurethose details don't change in the future. Specifically, KVM never useson-stack variables for accesses larger that 8 bytes, e.g. uses an operandin the emulator context, and *al---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()When lan966x_fdma_reload() fails to allocate new RX buffers, the restorepath restarts DMA using old descriptors whose pages were already freedvia lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() canrelease pages back to the buddy allocator, the hardware may DMA intomemory now owned by other kernel subsystems.Additionally, on the restore path, the newly created page pool (ifallocation partially succeeded) is overwritten without being destroyed,leaking it.Fix both issues by deferring the release of old pages until after thenew allocation succeeds. Save the old page array before the allocationso old pages can be freed on the success path. On the failure path, theold descriptors, pages and page pool are all still valid, making therestore safe. Also ensure the restore path re-enables NAPI and wakesthe netdev, matching the success path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix slab-use-after-free in __inet_lookup_establishedThe ehash table lookups are lockless and rely onSLAB_TYPESAFE_BY_RCU to guarantee socket memory stabilityduring RCU read-side critical sections. Both tcp_prot andtcpv6_prot have their slab caches created with this flagvia proto_register().However, MPTCP's mptcp_subflow_init() copies tcpv6_prot intotcpv6_prot_override during inet_init() (fs_initcall, level 5),before inet6_init() (module_init/device_initcall, level 6) hascalled proto_register(&tcpv6_prot). At that point,tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slabremains NULL permanently.This causes MPTCP v6 subflow child sockets to be allocated viakmalloc (falling into kmalloc-4k) instead of the TCPv6 slabcache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, sowhen these sockets are freed without SOCK_RCU_FREE (which iscleared for child sockets by design), the memory can beimmediately reused. Concurrent ehash lookups underrcu_read_lock can then access freed memory, triggering aslab-use-after-free in __inet_lookup_established.Fix this by splitting the IPv6-specific initialization out ofmptcp_subflow_init() into a new mptcp_subflow_v6_init(), calledfrom mptcp_proto_v6_init() before protocol registration. Thisensures tcpv6_prot_override.slab correctly inherits theSLAB_TYPESAFE_BY_RCU slab cache.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr pointsdirectly into the mmap'd TX ring buffer shared with userspace. Thekernel validates the header via __packet_snd_vnet_parse() but thenre-reads all fields later in virtio_net_hdr_to_skb(). A concurrentuserspace thread can modify the vnet_hdr fields between validationand use, bypassing all safety checks.The non-TPACKET path (packet_snd()) already correctly copies vnet_hdrto a stack-local variable. All other vnet_hdr consumers in the kernel(tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TXpath is the only caller of virtio_net_hdr_to_skb() that reads directlyfrom user-controlled shared memory.Fix this by copying vnet_hdr from the mmap'd ring buffer to astack-local variable before validation and use, consistent with theapproach used in packet_snd() and all other callers.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()smb_inherit_dacl() trusts the on-disk num_aces value from the parentdirectory's DACL xattr and uses it to size a heap allocation: aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);num_aces is a u16 read from le16_to_cpu(parent_pdacl->num_aces)without checking that it is consistent with the declared pdacl_size.An authenticated client whose parent directory's security.NTACL istampered (e.g. via offline xattr corruption or a concurrent path thatbypasses parse_dacl()) can present num_aces = 65535 with minimalactual ACE data. This causes a ~8 MB allocation (not kzalloc, souninitialized) that the subsequent loop only partially populates, andmay also overflow the three-way size_t multiply on 32-bit kernels.Additionally, the ACE walk loop uses the weakeroffsetof(struct smb_ace, access_req) minimum size check rather thanthe minimum valid on-wire ACE size, and does not reject ACEs whosedeclared size is below the minimum.Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.A legitimate mount.cifs client creates a parent directory over SMB(ksmbd writes a valid security.NTACL xattr), then the NTACL blob onthe backing filesystem is rewritten to set num_aces = 0xFFFF whilekeeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()'shash check still passes. A subsequent SMB2 CREATE of a child underthat parent drives smb2_open() into smb_inherit_dacl() (share has"vfs objects = acl_xattr" set), which fails the page allocator: WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0 Workqueue: ksmbd-io handle_ksmbd_work __alloc_frozen_pages_noprof+0x46c/0x9c0 ___kmalloc_large_node+0x68/0x130 __kmalloc_large_node_noprof+0x24/0x70 __kmalloc_noprof+0x4c9/0x690 smb_inherit_dacl+0x394/0x2430 smb2_open+0x595d/0xabe0 handle_ksmbd_work+0x3d3/0x1140With the patch applied the added guard rejects the tampered valuewith -EINVAL before any large allocation runs, smb2_open() falls backto smb2_create_sd_buffer(), and the child is created with a defaultSD. No warning, no splat.Fix by: 1. Validating num_aces against pdacl_size using the same formula applied in parse_dacl(). 2. Replacing the raw kmalloc(sizeof * num_aces * 2) with kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe allocation. 3. Tightening the per-ACE loop guard to require the minimum valid ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and rejecting under-sized ACEs, matching the hardening in smb_check_perm_dacl() and parse_dacl().v1 -> v2: - Replace the synthetic test-module splat in the changelog with a real-path UML + KASAN reproduction driven through mount.cifs and SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name in v1 since it does not exist in ksmbd. - Drop the commit-hash citation from the code comment per Namjae's review; keep the parse_dacl() pointer.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: ignore explicit helper on new expectationsUse the existing master conntrack helper, anything else is not reallysupported and it just makes validation more complicated, so just ignorewhat helper userspace suggests for this expectation.This was uncovered when validating CTA_EXPECT_CLASS via different helperprovided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350Allowing to read kernel memory bytes off the expectation boundary.CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspacevia netlink dump.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_helper: pass helper to expect cleanupnf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()to remove expectations belonging to the helper being unregistered.However, it passes NULL instead of the helper pointer as the dataargument, so expect_iter_me() never matches any expectation and allof them survive the cleanup.After unregister returns, nfnl_cthelper_del() frees the helperobject immediately. Subsequent expectation dumps or packet-driveninit_conntrack() calls then dereference the freed exp->helper,causing a use-after-free.Pass the actual helper pointer so expectations referencing it areproperly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in libcap. A local unprivileged user can exploit a Time-of-check-to-time-of-use (TOCTOU) race condition in the `cap_set_file()` function. This allows an attacker with write access to a parent directory to redirect file capability updates to an attacker-controlled file. By doing so, capabilities can be injected into or stripped from unintended executables, leading to privilege escalation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libcap2 < 2.73-160000.3.1 (version in image is 2.73-160000.2.2).
Description: When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written,2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process.This issue was fixed in version 4.10.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Crypt::Sodium::XS module versions prior to 0.000042, for Perl, include a vulnerable version of libsodiumlibsodium <= 1.0.20 or a version of libsodium released before December 30, 2025 contains a vulnerability documented as CVE-2025-69277 https://www.cve.org/CVERecord?id=CVE-2025-69277 .The libsodium vulnerability states:In atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.0.000042 includes a version of libsodium updated to 1.0.20-stable, released January 3, 2026, which includes a fix for the vulnerability.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libsodium26 < 1.0.21-160000.1.1 (version in image is 1.0.20-160000.3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix potencial OOB in get_file_all_info() for compound requestsWhen a compound request consists of QUERY_DIRECTORY + QUERY_INFO(FILE_ALL_INFORMATION) and the first command consumes nearly the entiremax_trans_size, get_file_all_info() would blindly call smbConvertToUTF16()with PATH_MAX, causing out-of-bounds write beyond the response buffer.In get_file_all_info(), there was a missing validation check forthe client-provided OutputBufferLength before copying the filename intoFileName field of the smb2_file_all_info structure.If the filename length exceeds the available buffer space, it could lead topotential buffer overflows or memory corruption during smbConvertToUTF16conversion. This calculating the actual free buffer size usingsmb2_calc_max_out_buf_len() and returning -EINVAL if the buffer isinsufficient and updating smbConvertToUTF16 to use the actual filenamelength (clamped by PATH_MAX) to ensure a safe copy operation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: validate EaNameLength in smb2_get_ea()smb2_get_ea() reads ea_req->EaNameLength from the client request andpasses it directly to strncmp() as the comparison length withoutverifying that the length of the name really is the size of the inputbuffer received.Fix this up by properly checking the size of the name based on the valuereceived and the overall size of the request, to prevent a laterstrncmp() call to use the length as a "trusted" size of the buffer.Without this check, uninitialized heap values might be slowly leaked tothe client.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: fix out-of-bounds access in ops_initnet_alloc_generic is called by net_alloc, which is called without anylocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. Itis read twice, first to allocate an array, then to set s.len, which islater used to limit the bounds of the array access.It is possible that the array is allocated and another thread isregistering a new pernet ops, increments max_gen_ptrs, which is then usedto set s.len with a larger than allocated length for the variable array.Fix it by reading max_gen_ptrs only once in net_alloc_generic. Ifmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: s3c24xx: check the size of the SMBUS message before using itThe first byte of an i2c SMBUS message is the size, and it should beverified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAXbefore processing it.This is the same logic that was added in commit a6e04f05ce0b ("i2c:tegra: check msg length in SMBUS block read") to the i2c tegra driver.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: validate MPLS set/set_masked payload lengthvalidate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload forSET/SET_MASKED actions. In action handling, OVS expects fixed-sizeMPLS key data (struct ovs_key_mpls).Use the already normalized key_len (masked case included) and rejectnon-matching MPLS action key sizes.Reject invalid MPLS action payload lengths early.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kasan: fix double free for kasan pXdskasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case ofpowerpc with 64K pagesize, PUD table (of size 4096) comes from slab cachenamed pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's justdirectly pass the start of the pxd table which is passed as the 1stargument.This fixes the below double free kasan issue seen with PMEM:radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages==================================================================BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20Free of addr c0000003c38e0000 by task ndctl/2164CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARYHardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeriesCall Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec---- interrupt: 3000 at 0x7fff93b3d3f4NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392)MSR: 800000000280f033 CR: 48888208 XER: 00000000<...>NIP [00007fff93b3d3f4] 0x7fff93b3d3f4LR [00007fff93b3d3f4] 0x7fff93b3d3f4---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected[ 138.953636] [ T2164] Memory state around the buggy address:[ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953669] [ T2164] ^[ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953692] [ T2164] ==================================================================[ 138.953701] [ T2164] Disabling lock debugging due to kernel taint
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:Buffer overflow in drivers/xen/sys-hypervisor.cThe build id returned by HYPERVISOR_xen_version(XENVER_build_id) isneither NUL terminated nor a string.The first causes a buffer overflow as sprintf in buildid_show willread and copy till it finds a NUL.00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P|00000010 b9 a8 01 42 6f 2e 32 |...Bo.2|00000017So use a memcpy instead of sprintf to have the correct value:00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P|00000010 b9 a8 01 42 |...B|00000014(the above have a hack to embed a zero inside and check it'sreturned correctly).This is XSA-485 / CVE-2026-31786
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
cockpit > 0-0 (version in image is 354-160000.3.1).
Description: A vulnerability was found in OpenJPEG similar to CVE-2019-6988. This flaw allows an attacker to bypass existing protections and cause an application crash through a maliciously crafted file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libopenjp2-7 > 0-0 (version in image is 2.5.3-160000.3.1).
Description: The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.6, tvOS 17, iOS 16.7 and iPadOS 16.7, macOS Monterey 12.7, watchOS 10, iOS 17 and iPadOS 17, macOS Sonoma 14. Processing web content may disclose sensitive information.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libexslt0 > 0-0 (version in image is 1.1.43-160000.4.1).
Description: A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate theprivileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'root_squash' or 'all_squash' attributes that would normally be expected to apply to that client.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libnfsidmap1 > 0-0 (version in image is 1.0-160000.2.2).
Description: The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g.
Packages affected:
podman > 0-0 (version in image is 5.4.2-160000.4.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: The API function `ssh_get_hexa()` is vulnerable, when 0-lenghtinput is provided to this function. This function is used internallyin `ssh_get_fingerprint_hash()` and `ssh_print_hexa()` (deprecated),which is vulnerable to the same input (length is provided by thecalling application).The function is also used internally in the gssapi code for loggingthe OIDs received by the server during GSSAPI authentication. Thiscould be triggered remotely, when the server allows GSSAPI authenticationand logging verbosity is set at least to SSH_LOG_PACKET (3). Thiscould cause self-DoS of the per-connection daemon process.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
Description: In the Linux kernel, the following vulnerability has been resolved:net: add xmit recursion limit to tunnel xmit functionsTunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their ownrecursion limit. When a bond device in broadcast mode has GRE tapinterfaces as slaves, and those GRE tunnels route back through thebond, multicast/broadcast traffic triggers infinite recursion betweenbond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causingkernel stack overflow.The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is notsufficient because tunnel recursion involves route lookups and full IPoutput, consuming much more stack per level. Use a lower limit of 4(IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.Add recursion detection using dev_xmit_recursion helpers directly iniptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnelpaths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).Move dev_xmit_recursion helpers from net/core/dev.h to public headerinclude/linux/netdevice.h so they can be used by tunnel code. BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mld_ifc_work Call Trace: __build_flow_key.constprop.0 (net/ipv4/route.c:515) ip_rt_update_pmtu (net/ipv4/route.c:1073) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) mld_sendpack mld_ifc_work process_one_work worker_thread
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQCurrently the code attempts to accept requests regardless of thecommand identifier which may cause multiple requests to be markedas pending (FLAG_DEFER_SETUP) which can cause more thanL2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defercausing an overflow.The spec is quite clear that the same identifier shall not be used onsubsequent requests:'Within each signaling channel a different Identifier shall be usedfor each successive request or indication.'https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355dSo this attempts to check if there are any channels pending with thesame identifier and rejects if any are found.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix NULL deref in mesh_matches_local()mesh_matches_local() unconditionally dereferences ie->mesh_config tocompare mesh configuration parameters. When called frommesh_rx_csa_frame(), the parsed action-frame elements may not contain aMesh Configuration IE, leaving ie->mesh_config NULL and triggering akernel NULL pointer dereference.The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, toomesh_rx_csa_frame() is the only caller that passes raw parsed elementsto mesh_matches_local() without guarding mesh_config. An adjacentattacker can exploit this by sending a crafted CSA action frame thatincludes a valid Mesh ID IE but omits the Mesh Configuration IE,crashing the kernel.The captured crash log:Oops: general protection fault, probably for non-canonical address ...KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]Workqueue: events_unbound cfg80211_wiphy_work[...]Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top ofmesh_matches_local() to return false early when the Mesh ConfigurationIE is absent.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libavahi-client3 > 0-0 (version in image is 0.8-160000.4.1).
Description: In the Linux kernel, the following vulnerability has been resolved:virt: tdx-guest: Fix handling of host controlled 'quote' buffer lengthValidate host controlled value `quote_buf->out_len` that determines howmany bytes of the quote are copied out to guest userspace. In TDXenvironments with remote attestation, quotes are not considered private,and can be forwarded to an attestation server.Catch scenarios where the host specifies a response length larger thanthe guest's allocation, or otherwise races modifying the response whilethe guest consumes it.This prevents contents beyond the pages allocated for `quote_buf`(up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace,and possibly forwarded in attestation requests.Recall that some deployments want per-container configs-tsm-reportinterfaces, so the leak may cross container protection boundaries, notjust local root.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_csum: validate nested VLAN headerstcf_csum_act() walks nested VLAN headers directly from skb->data when anskb still carries in-payload VLAN tags. The current code readsvlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes withoutfirst ensuring that the full VLAN header is present in the linear area.If only part of an inner VLAN header is linearized, accessingh_vlan_encapsulated_proto reads past the linear area, and the followingskb_pull(VLAN_HLEN) may violate skb invariants.Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing andpulling each nested VLAN header. If the header still is not fullyavailable, drop the packet through the existing error path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Active Storage allows users to attach cloud and local files in Rails applications. Prior to versions 8.1.2.1, 8.0.4.1, and 7.2.3.1, Active Storage's `DiskService#path_for` does not validate that the resolved filesystem path remains within the storage root directory. If a blob key containing path traversal sequences (e.g. `../`) is used, it could allow reading, writing, or deleting arbitrary files on the server. Blob keys are expected to be trusted strings, but some applications could be passing user input as keys and would be affected. Versions 8.1.2.1, 8.0.4.1, and 7.2.3.1 contain a patch.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
openssh > 0-0 (version in image is 10.0p2-160000.4.1).
Description: A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libxml2-2 > 0-0 (version in image is 2.13.8-160000.4.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_gate: snapshot parameters with RCU on replaceThe gate action can be replaced while the hrtimer callback or dump path iswalking the schedule list.Convert the parameters to an RCU-protected snapshot and swap updates undertcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omitsthe entry list, preserve the existing schedule so the effective state isunchanged.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error in mtk_xdp_setup()Reset eBPF program pointer to old_prog and do not decrease its ref-countif mtk_open routine in mtk_xdp_setup() fails.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shimThe root cause of this bug is that when 'bpf_link_put' reduces therefcount of 'shim_link->link.link' to zero, the resource is consideredreleased but may still be referenced via 'tr->progs_hlist' in'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in'bpf_shim_tramp_link_release' is deferred. During this window, anotherprocess can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.Based on Martin KaFai Lau's suggestions, I have created a simple patch.To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero.Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger:static void bpf_shim_tramp_link_release(struct bpf_link *link){ /* ... */ if (!shim_link->trampoline) return;+ msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline);}Before the patch, running a PoC easily reproduced the crash(almost 100%)with a call trace similar to KaiyanM's report.After the patch, the bug no longer occurs even after millions ofiterations.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscsWhen shrinking the number of real tx queues,netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flushqdiscs for queues which will no longer be used.qdisc_reset_all_tx_gt() currently serializes qdisc_reset() withqdisc_lock(). However, for lockless qdiscs, the dequeue path isserialized by qdisc_run_begin/end() using qdisc->seqlock instead, soqdisc_reset() can run concurrently with __qdisc_run() and free skbswhile they are still being dequeued, leading to UAF.This can easily be reproduced on e.g. virtio-net by imposing heavytraffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 doneWith KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ...Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path bytaking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching theserialization model already used by dev_reset_queue().Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc statereflects an empty queue, avoiding needless re-scheduling.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:clsact: Fix use-after-free in init/destroy rollback asymmetryFix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry.The latter is achieved by first fully initializing a clsact instance, andthen in a second step having a replacement failure for the new clsact qdiscinstance. clsact_init() initializes ingress first and then takes care of theegress part. This can fail midway, for example, via tcf_block_get_ext(). Uponfailure, the kernel will trigger the clsact_destroy() callback.Commit 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") details theway how the transition is happening. If tcf_block_get_ext on the q->ingress_blockends up failing, we took the tcx_miniq_inc reference count on the ingressside, but not yet on the egress side. clsact_destroy() tests whether the{ingress,egress}_entry was non-NULL. However, even in midway failure on thereplacement, both are in fact non-NULL with a valid egress_entry from theprevious clsact instance.What we really need to test for is whether the qdisc instance-specific ingressor egress side previously got initialized. This adds a small helper for checkingthe miniq initialization called mini_qdisc_pair_inited, and utilizes that uponclsact_destroy() in order to fix the use-after-free scenario. Convert theingress_destroy() side as well so both are consistent to each other.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfs: Fix read abandonment during retryUnder certain circumstances, all the remaining subrequests from a readrequest will get abandoned during retry. The abandonment process expectsthe 'subreq' variable to be set to the place to start abandonment from, butit doesn't always have a useful value (it will be uninitialised on thefirst pass through the loop and it may point to a deleted subrequest onlater passes).Fix the first jump to "abandon:" to set subreq to the start of the firstsubrequest expected to need retry (which, in this abandonment case, turnedout unexpectedly to no longer have NEED_RETRY set).Also clear the subreq pointer after discarding superfluous retryablesubrequests to cause an oops if we do try to access it.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/efa: Fix use of completion ctx after freeOn admin queue completion handling, if the admin command completed witherror we print data from the completion context. The issue is that wealready freed the completion context in polling/interrupts handler whichmeans we print data from context in an unknown state (it might bealready used again).Change the admin submission flow so alloc/dealloc of the context will besymmetric and dealloc will be called after any potential use of thecontext.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:team: fix header_ops type confusion with non-Ethernet portsSimilar to commit 950803f72547 ("bonding: fix type confusion inbond_setup_by_slave()") team has the same class of header_ops typeconfusion.For non-Ethernet ports, team_setup_by_port() copies port_dev->header_opsdirectly. When the team device later calls dev_hard_header() ordev_parse_header(), these callbacks can run with the team net_deviceinstead of the real lower device, so netdev_priv(dev) is interpreted asthe wrong private type and can crash.The syzbot report shows a crash in bond_header_create(), but the rootcause is in team: the topology is gre -> bond -> team, and team callsthe inherited header_ops with its own net_device instead of the lowerdevice, so bond_header_create() receives a team device and interpretsnetdev_priv() as bonding private data, causing a type confusion crash.Fix this by introducing team header_ops wrappers for create/parse,selecting a team port under RCU, and calling the lower device callbackswith port->dev, so each callback always sees the correct net_devicecontext.Also pass the selected lower device to the lower parse callback, sorecursion is bounded in stacked non-Ethernet topologies and parsecallbacks always run with the correct device context.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: prevent policy_hthresh.work from racing with netns teardownA XFRM_MSG_NEWSPDINFO request can queue the per-net work itempolicy_hthresh.work onto the system workqueue.The queued callback, xfrm_hash_rebuild(), retrieves the enclosingstruct net via container_of(). If the net namespace is torn downbefore that work runs, the associated struct net may already havebeen freed, and xfrm_hash_rebuild() may then dereference stale memory.xfrm_policy_fini() already flushes policy_hash_work during teardown,but it does not synchronize policy_hthresh.work.Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so thequeued work cannot outlive the net namespace teardown and access afreed struct net.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: platform: use generic driver_override infrastructureWhen a driver is probed through __driver_attach(), the bus' match()callback is called without the device lock held, thus accessing thedriver_override field without a lock, which can cause a UAF.Fix this by using the driver-core driver_override infrastructure takingcare of proper locking internally.Note that calling match() from __driver_attach() without the device lockheld is intentional. [1]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Fix use after free of parent_port in cxl_detach_ep()cxl_detach_ep() is called during bottom-up removal when all CXL memorydevices beneath a switch port have been removed. For each port in thehierarchy it locks both the port and its parent, removes the endpoint,and if the port is now empty, marks it dead and unregisters the portby calling delete_switch_port(). There are two places during this workwhere the parent_port may be used after freeing:First, a concurrent detach may have already processed a port by thetime a second worker finds it via bus_find_device(). Without pinningparent_port, it may already be freed when we discover port->dead andattempt to unlock the parent_port. In a production kernel that's asilent memory corruption, with lock debug, it looks like this:[]DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())[]WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310[]Call Trace:[]mutex_unlock+0xd/0x20[]cxl_detach_ep+0x180/0x400 [cxl_core][]devm_action_release+0x10/0x20[]devres_release_all+0xa8/0xe0[]device_unbind_cleanup+0xd/0xa0[]really_probe+0x1a6/0x3e0Second, delete_switch_port() releases three devm actions registeredagainst parent_port. The last of those is unregister_port() and itcalls device_unregister() on the child port, which can cascade. Ifparent_port is now also empty the device core may unregister and freeit too. So by the time delete_switch_port() returns, parent_port maybe free, and the subsequent device_unlock(&parent_port->dev) operateson freed memory. The kernel log looks same as above, with a differentoffset in cxl_detach_ep().Both of these issues stem from the absence of a lifetime guaranteebetween a child port and its parent port.Establish a lifetime rule for ports: child ports hold a reference totheir parent device until release. Take the reference when the portis allocated and drop it when released. This ensures the parent isvalid for the full lifetime of the child and eliminates the use afterfree window in cxl_detach_ep().This is easily reproduced with a reload of cxl_acpi in QEMU with CXLdevices present.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: hold dev ref until after transport_finish NF_HOOKAfter async crypto completes, xfrm_input_resume() calls dev_put()immediately on re-entry before the skb reaches transport_finish.The skb->dev pointer is then used inside NF_HOOK and its okfn,which can race with device teardown.Remove the dev_put from the async resumption entry and insteaddrop the reference after the NF_HOOK call in transport_finish,using a saved device pointer since NF_HOOK may consume the skb.This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skipthe okfn.For non-transport exits (decaps, gro, drop) and secondaryasync return points, release the reference inline whenasync is set.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: fix use-after-free in timeout object destroynft_ct_timeout_obj_destroy() frees the timeout object with kfree()immediately after nf_ct_untimeout(), without waiting for an RCU graceperiod. Concurrent packet processing on other CPUs may still holdRCU-protected references to the timeout object obtained viarcu_dereference() in nf_ct_timeout_data().Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to deferfreeing until after an RCU grace period, matching the approach alreadyused in nfnetlink_cttimeout.c.KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: defer tunnel netdev_put to RCU releaseovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER alreadydetached the device. Dropping the netdev reference in destroy can racewith concurrent readers that still observe vport->dev.Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, letvport_netdev_free() drop the reference from the RCU callback, matchingthe non-tunnel destroy path and avoiding additional synchronizationunder RTNL.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:driver core: enforce device_lock for driver_match_device()Currently, driver_match_device() is called from three sites. One site(__device_attach_driver) holds device_lock(dev), but the other two(bind_store and __driver_attach) do not. This inconsistency means thatbus match() callbacks are not guaranteed to be called with the lockheld.Fix this by introducing driver_match_device_locked(), which guaranteesholding the device lock using a scoped guard. Replace the unlocked callsin bind_store() and __driver_attach() with this new helper. Also add alock assertion to driver_match_device() to enforce this guarantee.This consistency also fixes a known race condition. The driver_overrideimplementation relies on the device_lock, so the missing lock led to theuse-after-free (UAF) reported in Bugzilla for buses using this field.Stress testing the two newly locked paths for 24 hours withCONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrenceand no lockdep warnings.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:gve: Fix stats report corruption on queue count changeThe driver and the NIC share a region in memory for stats reporting.The NIC calculates its offset into this region based on the total sizeof the stats region and the size of the NIC's stats.When the number of queues is changed, the driver's stats region isresized. If the queue count is increased, the NIC can write pastthe end of the allocated stats region, causing memory corruption.If the queue count is decreased, there is a gap between the driverand NIC stats, leading to incorrect stats reporting.This change fixes the issue by allocating stats region with maximumsize, and the offset calculation for NIC stats is changed to matchwith the calculation of the NIC.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix use-after-free in lbs_free_adapter()The lbs_free_adapter() function uses timer_delete() (non-synchronous)for both command_timer and tx_lockup_timer before the structure isfreed. This is incorrect because timer_delete() does not wait forany running timer callback to complete.If a timer callback is executing when lbs_free_adapter() is called,the callback will access freed memory since lbs_cfg_free() frees thecontaining structure immediately after lbs_free_adapter() returns.Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler)access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields,which would all be use-after-free violations.Use timer_delete_sync() instead to ensure any running timer callbackhas completed before returning.This bug was introduced in commit 8f641d93c38a ("libertas: detect TXlockups and reset hardware") where del_timer() was used instead ofdel_timer_sync() in the cleanup path. The command_timer has had thesame issue since the driver was first written.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()Even though we check that we "should" be able to do lc_get_cumulative()while holding the device->al_lock spinlock, it may still fail,if some other code path decided to do lc_try_lock() with bad timing.If that happened, we logged "LOGIC BUG for enr=...",but still did not return an error.The rest of the code now assumed that this request has referencesfor the relevant activity log extents.The implcations are that during an active resync, mutual exclusivity ofresync versus application IO is not guaranteed. And a potential crashat this point may not realizs that these extents could have been targetof in-flight IO and would need to be resynced just in case.Also, once the request completes, it will give up activity log references itdoes not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().Fix:Do not crash the kernel for a condition that is harmless during normaloperation: also catch "e->refcnt == 0", not only "e == NULL"when being noisy about "al_complete_io() called on inactive extent %u\n".And do not try to be smart and "guess" whether something will work, thenbe surprised when it does not.Deal with the fact that it may or may not work. If it does not, remember apossible "partially in activity log" state (only possible for requests thatcross extent boundaries), and return an error code fromdrbd_al_begin_io_nonblock().A latter call for the same request will then resume from where we left off.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check metadata block offset is within rangeSyzkaller reports a "general protection fault in squashfs_copy_data"This is ultimately caused by a corrupted index look-up table, whichproduces a negative metadata block offset.This is subsequently passed to squashfs_copy_data (viasquashfs_read_metadata) where the negative offset causes an out of boundsaccess.The fix is to check that the offset is within range insquashfs_read_metadata. This will trap this and other cases.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Fix ID register initialization for non-protected pKVM guestsIn protected mode, the hypervisor maintains a separate instance ofthe `kvm` structure for each VM. For non-protected VMs, this structure isinitialized from the host's `kvm` state.Currently, `pkvm_init_features_from_host()` copies the`KVM_ARCH_FLAG_ID_REGS_INITIALIZED` flag from the host without theunderlying `id_regs` data being initialized. This results in thehypervisor seeing the flag as set while the ID registers remain zeroed.Consequently, `kvm_has_feat()` checks at EL2 fail (return 0) fornon-protected VMs. This breaks logic that relies on feature detection,such as `ctxt_has_tcrx()` for TCR2_EL1 support. As a result, certainsystem registers (e.g., TCR2_EL1, PIR_EL1, POR_EL1) are notsaved/restored during the world switch, which could lead to statecorruption.Fix this by explicitly copying the ID registers from the host `kvm` tothe hypervisor `kvm` for non-protected VMs during initialization, sincewe trust the host with its non-protected guests' features. Also ensure`KVM_ARCH_FLAG_ID_REGS_INITIALIZED` is cleared initially in`pkvm_init_features_from_host` so that `vm_copy_id_regs` can properlyinitialize them and set the flag once done.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix OOB write in QUERY_INFO for compound requestsWhen a compound request such as READ + QUERY_INFO(Security) is received,and the first command (READ) consumes most of the response buffer,ksmbd could write beyond the allocated buffer while building a securitydescriptor.The root cause was that smb2_get_info_sec() checked buffer space usingppntsd_size from xattr, while build_sec_desc() often synthesized asignificantly larger descriptor from POSIX ACLs.This patch introduces smb_acl_sec_desc_scratch_len() to accuratelycompute the final descriptor size beforehand, performs proper bufferchecking with smb2_calc_max_out_buf_len(), and uses exact-sizedallocation + iov pinning.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, Iencountered some very strange crash issues showing up as "Bad page state":"[ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb[ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb[ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff)[ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000[ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000[ 734.496442] page dumped because: nonzero mapcount"After analyzing this page's state, it is hard to understand why themapcount is not 0 while the refcount is 0, since this page is not wherethe issue first occurred. By enabling the CONFIG_DEBUG_VM config, I canreproduce the crash as well and captured the first warning where the issueappears:"[ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0[ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0[ 734.469315] memcg:ffff000807a8ec00[ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540"[ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff)......[ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1),const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *:(struct folio *)_compound_head(page + nr_pages - 1))) != folio)[ 734.469390] ------------[ cut here ]------------[ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468,CPU#90: stress-ng-mlock/9430[ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P)[ 734.469555] set_pte_range+0xd8/0x2f8[ 734.469566] filemap_map_folio_range+0x190/0x400[ 734.469579] filemap_map_pages+0x348/0x638[ 734.469583] do_fault_around+0x140/0x198......[ 734.469640] el0t_64_sync+0x184/0x188"The code that triggers the warning is: "VM_WARN_ON_FOLIO(page_folio(page +nr_pages - 1) != folio, folio)", which indicates that set_pte_range()tried to map beyond the large folio's size.By adding more debug information, I found that 'nr_pages' had overflowedin filemap_map_pages(), causing set_pte_range() to establish mappings fora range exceeding the folio size, potentially corrupting fields of pagesthat do not belong to this folio (e.g., page->_mapcount).After above analysis, I think the possible race is as follows:CPU 0 CPU 1filemap_map_pages() ext4_setattr() //get and lock folio with old inode->i_size next_uptodate_folio() ....... //shrink the inode->i_size i_size_write(inode, attr->ia_size); //calculate the end_pgoff with the new inode->i_size file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; end_pgoff = min(end_pgoff, file_end); ...... //nr_pages can be overflowed, cause xas.xa_index > end_pgoff end = folio_next_index(folio) - 1; nr_pages = min(end, end_pgoff) - xas.xa_index + 1; ...... //map large folio filemap_map_folio_range() ...... //truncate folios truncate_pagecache(inode, inode->i_size);To fix this issue, move the 'end_pgoff' calculation beforenext_uptodate_folio(), so the retrieved folio stays consistent with thefile end to avoid ---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. From versions 2.0.0-alpha to before 2.3.9 and 3.0.0-alpha to before 3.1.1, there is a conditional local privilege escalation vulnerability in an edge-case naming collision. Only authenticated himmelblau users whose mapped CN/short name exactly matches a privileged local group name (e.g., "sudo", "wheel", "docker", "adm") can cause the NSS module to resolve that group name to their fake primary group. If the system uses NSS results for group-based authorization decisions (sudo, polkit, etc.), this can grant the attacker the privileges of that group. This issue has been patched in versions 2.3.9 and 3.1.1.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
himmelblau < 2.3.9+git0.a9fd29b-160000.1.1 (version in image is 2.3.8+git0.dec3693-160000.1.1).
Description: Libgcrypt before 1.12.2 sometimes allows a heap-based buffer overflow and denial of service via crafted ECDH ciphertext to gcry_pk_decrypt.
Packages affected:
grub2 > 0-0 (version in image is 2.12-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: AIDE is an advanced intrusion detection environment. Prior to version 0.19.2, there is an improper output neutralization vulnerability in AIDE. An attacker can craft a malicious filename by including terminal escape sequences to hide the addition or removal of the file from the report and/or tamper with the log output. A local user might exploit this to bypass the AIDE detection of malicious files. Additionally the output of extended attribute key names and symbolic links targets are also not properly neutralized. This issue has been patched in version 0.19.2. A workaround involves configuring AIDE to write the report output to a regular file, redirecting stdout to a regular file, or redirecting the log output written to stderr to a regular file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
aide > 0-0 (version in image is 0.18.8-160000.2.2).
Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ("nfs: add support for large folios")).
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: validate DFA start states are in bounds in unpack_pdbStart states are read from untrusted data and used as indexes into theDFA state tables. The aa_dfa_next() function call in unpack_pdb() willaccess dfa->tables[YYTD_ID_BASE][start], and if the start state exceedsthe number of states in the DFA, this results in an out-of-bound read.================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...Reject policies with out-of-bounds start states during unpackingto prevent the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix wildcard bind conflict check when using hash2When binding a udp_sock to a local address and port, UDP usestwo hashes (udptable->hash and udptable->hash2) for collisiondetection. The current code switches to "hash2" whenhslot->count > 10."hash2" is keyed by local address and local port."hash" is keyed by local port only.The issue can be shown in the following bind sequence (pseudo code):bind(fd1, "[fd00::1]:8888")bind(fd2, "[fd00::2]:8888")bind(fd3, "[fd00::3]:8888")bind(fd4, "[fd00::4]:8888")bind(fd5, "[fd00::5]:8888")bind(fd6, "[fd00::6]:8888")bind(fd7, "[fd00::7]:8888")bind(fd8, "[fd00::8]:8888")bind(fd9, "[fd00::9]:8888")bind(fd10, "[fd00::10]:8888")/* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udp_lib_lport_inuse() detects the * conflict. */bind(fail_fd, "[::]:8888")/* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. */bind(fd11, "[fd00::11]:8888")bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */The same issue applies to the IPv4 wildcard address "0.0.0.0"and the IPv4-mapped wildcard address "::ffff:0.0.0.0". Forexample, if there are existing sockets bound to"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or"[::ffff:0.0.0.0]:8888" can also miss the conflict whenhslot->count > 10.TCP inet_csk_get_port() already has the correct check ininet_use_bhash2_on_bind(). Rename it toinet_use_hash2_on_bind() and move it to inet_hashtables.hso udp.c can reuse it in this fix.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()A broken/bored/mean USB host can overflow the skb_shared_info->frags[]array on a Linux gadget exposing a Phonet function by sending anunbounded sequence of full-page OUT transfers.pn_rx_complete() finalizes the skb only when req->actual < req->length,where req->length is set to PAGE_SIZE by the gadget. If the host alwayssends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never bereset and each completion will add another fragment viaskb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17),subsequent frag stores overwrite memory adjacent to the shinfo on theheap.Drop the skb and account a length error when the frag limit is reached,matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan:t7xx: fix potential skb->frags overflow in RX path").
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in GNU Binutils. This heap-based buffer overflow vulnerability, specifically an out-of-bounds read in the bfd linker, allows an attacker to gain access to sensitive information. By convincing a user to process a specially crafted XCOFF object file, an attacker can trigger this flaw, potentially leading to information disclosure or an application level denial of service.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: A flaw was found in GNU Binutils. This vulnerability, a heap-based buffer overflow, specifically an out-of-bounds read, exists in the bfd linker component. An attacker could exploit this by convincing a user to process a specially crafted malicious XCOFF object file. Successful exploitation may lead to the disclosure of sensitive information or cause the application to crash, resulting in an application level denial of service.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: A flaw was found in the GNU Binutils BFD library, a widely used component for handling binary files such as object files and executables. The issue occurs when processing specially crafted XCOFF object files, where a relocation type value is not properly validated before being used. This can cause the program to read memory outside of intended bounds. As a result, affected tools may crash or expose unintended memory contents, leading to denial-of-service or limited information disclosure risks.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix use-after-free in pm8001_queue_command()Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") refactorspm8001_queue_command(), however it introduces a potential cause of a doublefree scenario when it changes the function to return -ENODEV in case of phydown/device gone state.In this path, pm8001_queue_command() updates task status and callstask_done to indicate to upper layer that the task has been handled.However, this also frees the underlying SAS task. A -ENODEV is thenreturned to the caller. When libsas sas_ata_qc_issue() receives this errorvalue, it assumes the task wasn't handled/queued by LLDD and proceeds toclean up and free the task again, resulting in a double free.Since pm8001_queue_command() handles the SAS task in this case, it shouldreturn 0 to the caller indicating that the task has been handled.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libgcrypt20 < 1.12.1-160000.1.1 (version in image is 1.11.1-160000.2.2).
Description: c-ares is an asynchronous resolver library. Versions 1.32.3 through 1.34.5 terminate a query after maximum attempts when using read_answer() and process_answer(), which can cause a Denial of Service. This issue is fixed in version 1.34.6.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libcares2 > 0-0 (version in image is 1.34.5-160000.2.2).
Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
gpg2 > 0-0 (version in image is 2.5.5-160000.5.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix double-free in nr_route_frame()In nr_route_frame(), old_skb is immediately freed without checking ifnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,the caller function will free old_skb again, causing a double-free bug.Therefore, to prevent this, we need to modify it to check whethernr_neigh->ax25 is NULL before freeing old_skb.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmitteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmitthrough slave devices, but does not update skb->dev to the slave devicebeforehand.When a gretap tunnel is a TEQL slave, the transmit path reachesiptunnel_xmit() which saves dev = skb->dev (still pointing to teql0master) and later calls iptunnel_xmit_stats(dev, pkt_len). Thisfunction does: get_cpu_ptr(dev->tstats)Since teql_master_setup() does not set dev->pcpu_stat_type toNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstatsfor teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computesNULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)Fix this by setting skb->dev = slave before callingnetdev_start_xmit(), so that tunnel xmit functions see the correctslave device with properly allocated tstats.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. If an IPv6 packet is injected into the interface,route_shortcircuit() is called and a NULL pointer dereference happens onneigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix this by adding an early check on route_shortcircuit() when protocolis ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here becauseVXLAN can be built-in even when IPv6 is built as a module.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:icmp: fix NULL pointer dereference in icmp_tag_validation()icmp_tag_validation() unconditionally dereferences the result ofrcu_dereference(inet_protos[proto]) without checking for NULL.The inet_protos[] array is sparse -- only about 15 of 256 protocolnumbers have registered handlers. When ip_no_pmtu_disc is set to 3(hardened PMTU mode) and the kernel receives an ICMP FragmentationNeeded error with a quoted inner IP header containing an unregisteredprotocol number, the NULL dereference causes a kernel panic insoftirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If theprotocol has no registered handler, return false since it cannotperform strict tag validation.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Only put the call ref if one was acquiredrxrpc_input_packet_on_conn() can process a to-client packet after thecurrent client call on the channel has already been torn down. In thatcase chan->call is NULL, rxrpc_try_get_call() returns NULL and there isno reference to drop.The client-side implicit-end error path does not account for that andunconditionally calls rxrpc_put_call(). This turns a protocol errorpath into a kernel crash instead of rejecting the packet.Only drop the call reference if one was actually acquired. Keep theexisting protocol error handling unchanged.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Calling NSS-backed functions that support caching via nscd may call the nscd client side code and in the GNU C Library version 2.36 under high load on x86_64 systems, the client may call memcmp on inputs that are concurrently modified by other processes or threads and crash.The nscd client in the GNU C Library uses the memcmp function with inputs that may be concurrently modified by another thread, potentially resulting in spurious cache misses, which in itself is not a security issue. However in the GNU C Library version 2.36 an optimized implementation of memcmp was introduced for x86_64 which could crash when invoked with such undefined behaviour, turning this into a potential crash of the nscd client and the application that uses it. This implementation was backported to the 2.35 branch, making the nscd client in that branch vulnerable as well. Subsequently, the fix for this issue was backported to all vulnerable branches in the GNU C Library repository.It is advised that distributions that may have cherry-picked the memcpy SSE2 optimization in their copy of the GNU C Library, also apply the fix to avoid the potential crash in the nscd client.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glibc > 0-0 (version in image is 2.40-160000.4.1).
Description: In MIT Kerberos 5 (aka krb5) before 1.22.3, there is a NULL pointer dereference if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, causing the process to terminate in parse_nego_message.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
krb5 > 0-0 (version in image is 1.21.3-160000.2.2).
Description: In MIT Kerberos 5 (aka krb5) before 1.22.3, there is an integer underflow and resultant out-of-bounds read if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, possibly causing the process to terminate in parse_message.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
krb5 > 0-0 (version in image is 1.21.3-160000.2.2).
Description: lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.0, using either of the two parsers in the default configuration (with resolve_entities=True) allows untrusted XML input to read local files. Setting the resolve_entities option explicitly to resolve_entities='internal' or resolve_entities=False disables the local file access. This vulnerability is fixed in 6.1.0.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313-lxml > 0-0 (version in image is 5.4.0-160000.2.2).
Description: Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glibc > 0-0 (version in image is 2.40-160000.4.1).
Description: slab is a pre-allocated storage for a uniform data type. In version 0.4.10, the get_disjoint_mut method incorrectly checked if indices were within the slab's capacity instead of its length, allowing access to uninitialized memory. This could lead to undefined behavior or potential crashes. This has been fixed in slab 0.4.11. A workaround for this issue involves to avoid using get_disjoint_mut with indices that might be beyond the slab's actual length.
Packages affected:
himmelblau > 0-0 (version in image is 2.3.8+git0.dec3693-160000.1.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, a possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions. When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls. An attacker could exploit this by setting a crafted `x-sendfile-type: x-accel-redirect` header, setting a crafted `x-accel-mapping` header, and requesting a path that qualifies for proxy-based acceleration. Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes. This issue only affected systems meeting all of the following conditions: The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx); the proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers; and the application exposed an endpoint that returned a body responding to `.to_path`. Users should upgrade to Rack versions 2.2.20, 3.1.18, or 3.2.3, which require explicit configuration to enable `x-accel-redirect`. Alternatively, configure the proxy to always set or strip the header, or in Rails applications, disable sendfile completely.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: ipc: fix use-after-free in ipc_msg_send_requestipc_msg_send_request() waits for a generic netlink reply using anipc_msg_table_entry on the stack. The generic netlink handler(handle_generic_event()/handle_response()) fills entry->response underipc_msg_table_lock, but ipc_msg_send_request() used to validate and freeentry->response without holding the same lock.Under high concurrency this allows a race where handle_response() iscopying data into entry->response while ipc_msg_send_request() has justfreed it, leading to a slab-use-after-free reported by KASAN inhandle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]Fix by:- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table.- Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock.- Returning NULL in the error path, preserving the original API semantics.This makes all accesses to entry->response consistent withhandle_response(), which already updates and fills the response bufferunder ipc_msg_table_lock, and closes the race that allowed the UAF.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()In iscsit_dec_session_usage_count(), the function calls complete() whileholding the sess->session_usage_lock. Similar to the connection usage countlogic, the waiter signaled by complete() (e.g., in the session releasepath) may wake up and free the iscsit_session structure immediately.This creates a race condition where the current thread may attempt toexecute spin_unlock_bh() on a session structure that has already beendeallocated, resulting in a KASAN slab-use-after-free.To resolve this, release the session_usage_lock before calling complete()to ensure all dereferences of the sess pointer are finished before thewaiter is allowed to proceed with deallocation.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: Giflib contains a double-free vulnerability that is the result of a shallow copy in GifMakeSavedImage and incorrect error handling. The conditions needed to trigger this vulnerability are difficult but may be possible.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libgif7 < 5.2.2-160000.3.1 (version in image is 5.2.2-160000.2.2).
Description: pip prior to version 26.1 would run self-update check functionality after installing wheel files which required importing well-known Python modules names. These module imports were intentionally deferred to increase startup time of the pip CLI. The patch changes self-update functionality to run before wheels are installed to prevent newly-installed modules from being imported shortly after the installation of a wheel package. Users should still review package contents prior to installation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: Calling the ungetwc function on a FILE stream with wide characters encoded in a character set that has overlaps between its single byte and multi-byte character encodings, in the GNU C Library version 2.43 or earlier, may result in an attempt to read bytes before an allocated buffer, potentially resulting in unintentional disclosure of neighboring data in the heap, or a program crash.A bug in the wide character pushback implementation (_IO_wdefault_pbackfail in libio/wgenops.c) causes ungetwc() to operate on the regular character buffer (fp->_IO_read_ptr) instead of the actual wide-stream read pointer (fp->_wide_data->_IO_read_ptr). The program crash may happen in cases where fp->_IO_read_ptr is not initialized and hence points to NULL. The buffer under-read requires a special situation where the input character encoding is such that there are overlaps between single byte representations and multibyte representations in that encoding, resulting in spurious matches. The spurious match case is not possible in the standard Unicode character sets.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glibc > 0-0 (version in image is 2.40-160000.4.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stack-out-of-bounds write in devmapget_upper_ifindexes() iterates over all upper devices and writes theirindices into an array without checking bounds.Also the callers assume that the max number of upper devices isMAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,but that assumption is not correct and the number of upper devices couldbe larger than MAX_NEST_DEV (e.g., many macvlans), causing astack-out-of-bounds write.Add a max parameter to get_upper_ifindexes() to avoid the issue.When there are too many upper devices, return -EOVERFLOW and abort theredirect.To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device withan XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.Then send a packet to the device to trigger the XDP redirect path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_netem: fix out-of-bounds access in packet corruptionIn netem_enqueue(), the packet corruption logic usesget_random_u32_below(skb_headlen(skb)) to select an index formodifying skb->data. When an AF_PACKET TX_RING sends fully non-linearpackets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.Passing 0 to get_random_u32_below() takes the variable-ceil slow pathwhich returns an unconstrained 32-bit random integer. Using thisunconstrained value as an offset into skb->data results in anout-of-bounds memory access.Fix this by verifying skb_headlen(skb) is non-zero before attemptingto corrupt the linear data area. Fully non-linear packets will silentlybypass the corruption logic.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: only handle RESPONSE during service challengeOnly process RESPONSE packets while the service connection is still inRXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock beforerunning response verification and security initialization, then use a localsecured flag to decide whether to queue the secured-connection work afterthe state transition. This keeps duplicate or late RESPONSE packets fromre-running the setup path and removes the unlocked post-transition statetest.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: support non-r10 register spill/fill to/from stack in precision trackingUse instruction (jump) history to record instructions that performedregister spill/fill to/from stack, regardless if this was done throughread-only r10 register, or any other register after copying r10 into it*and* potentially adjusting offset.To make this work reliably, we push extra per-instruction flags intoinstruction history, encoding stack slot index (spi) and stack framenumber in extra 10 bit flags we take away from prev_idx in instructionhistory. We don't touch idx field for maximum performance, as it'schecked most frequently during backtracking.This change removes basically the last remaining practical limitation ofprecision backtracking logic in BPF verifier. It fixes knowndeficiencies, but also opens up new opportunities to reduce number ofverified states, explored in the subsequent patches.There are only three differences in selftests' BPF object filesaccording to veristat, all in the positive direction (less states).File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)Note, I avoided renaming jmp_history to more generic insn_hist tominimize number of lines changed and potential merge conflicts betweenbpf and bpf-next trees.Notice also cur_hist_entry pointer reset to NULL at the beginning ofinstruction verification loop. This pointer avoids the problem ofrelying on last jump history entry's insn_idx to determine whether wealready have entry for current instruction or not. It can happen that weadded jump history entry because current instruction is_jmp_point(), butalso we need to add instruction flags for stack access. In this case, wedon't want to entries, so we need to reuse last added entry, if it ispresent.Relying on insn_idx comparison has the same ambiguity problem as the onethat was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: hold queue_lock when removing blkg->q_nodeWhen blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lockhas to be held, otherwise, all kinds of bugs(list corruption, hard lockup,..) can be triggered from blkg_destroy_all().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/xattr: missing fdput() in fremovexattr error pathIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire afile reference but returns early without calling fdput() whenstrncpy_from_user() fails on the name argument. In multi-threaded processeswhere fdget() takes the slow path, this permanently leaks onefile reference per call, pinning the struct file and associated kernelobjects in memory. An unprivileged local user can exploit this to causekernel memory exhaustion. The issue was inadvertently fixed by commita71874379ec8 ("xattr: switch to CLASS(fd)").
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix missing hugetlb_lock for resv unchargeThere is a recent report on UFFDIO_COPY over hugetlb:https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/350: lockdep_assert_held(&hugetlb_lock);Should be an issue in hugetlb but triggered in an userfault context, whereit goes into the unlikely path where two threads modifying the resv maptogether. Mike has a fix in that path for resv uncharge but it looks likethe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()will update the cgroup pointer, so it requires to be called with the lockheld.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:vsock: fix recursive ->recvmsg callsAfter a vsock socket has been added to a BPF sockmap, its prot->recvmsghas been replaced with vsock_bpf_recvmsg(). Thus the followingrecursiion could happen:vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() againWe need to fix it by calling the original ->recvmsg() without any BPFsockmap logic in __vsock_recvmsg().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve leaks in cow_file_rangeIn the buffered write path, the dirty page owns the qgroup reserve untilit creates an ordered_extent.Therefore, any errors that occur before the ordered_extent is createdmust free that reservation, or else the space is leaked. The fstestgeneric/475 exercises various IO error paths, and is able to triggererrors in cow_file_range where we fail to get to allocating the orderedextent. Note that because we *do* clear delalloc, we are likely toremove the inode from the delalloc list, so the inodes/pages to not haveinvalidate/launder called on them in the commit abort path.This results in failures at the unmount stage of the test that look like: BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leakedCases 2 and 3 in the out_reserve path both pertain to this type of leakand must free the reserved qgroup data. Because it is already an errorpath, I opted not to handle the possible errors inbtrfs_free_qgroup_data.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:sched/numa: Fix the potential null pointer dereference in task_numa_work()When running stress-ng-vm-segv test, we found a null pointer dereferenceerror in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel...stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV errorhandling function of the system, which tries to cause a SIGSEGV error onreturn from unmapping the whole address space of the child process.Normally this program will not cause kernel crashes. But before themunmap system call returns to user mode, a potential task_numa_work()for numa balancing could be added and executed. In this scenario, since thechild process has no vma after munmap, the vma_next() in task_numa_work()will return a null pointer even if the vma iterator restarts from 0.Recheck the vma pointer before dereferencing it in task_numa_work().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx93-blk-ctrl: correct remove pathThe check condition should be 'i < bc->onecell_data.num_domains', not'bc->onecell_data.num_domains' which will make the look never finishand cause kernel panic.Also disable runtime to address"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix possible int overflows in nilfs_fiemap()Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its resultby being prepared to go through potentially maxblocks == INT_MAX blocks,the value in n may experience an overflow caused by left shift of blkbits.While it is extremely unlikely to occur, play it safe and cast right handexpression to wider type to mitigate the issue.Found by Linux Verification Center (linuxtesting.org) with static analysistool SVACE.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: don't ignore the return code of svc_proc_register()Currently, nfsd_proc_stat_init() ignores the return value ofsvc_proc_register(). If the procfile creation fails, then the kernelwill WARN when it tries to remove the entry later.Fix nfsd_proc_stat_init() to return the same type of pointer assvc_proc_register(), and fix up nfsd_net_init() to check that and failthe nfsd_net construction if it occurs.svc_proc_register() can fail if the dentry can't be allocated, or if anidentical dentry already exists. The second case is pretty unlikely inthe nfsd_net construction codepath, so if this happens, return -ENOMEM.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: KVM: Fix stack protector issue in send_ipi_data()Function kvm_io_bus_read() is called in function send_ipi_data(), buffersize of parameter *val should be at least 8 bytes. Since some emulationfunctions like loongarch_ipi_readl() and kvm_eiointc_read() will writethe buffer *val with 8 bytes signed extension regardless parameter len.Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTORis enabled. The bug report is shown as follows:Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ...Call Trace:[<9000000003af3734>] show_stack+0x5c/0x180[<9000000003aed168>] dump_stack_lvl+0x6c/0x9c[<9000000003ad0ab0>] vpanic+0x108/0x2c4[<9000000003ad0ca8>] panic+0x3c/0x40[<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18[] send_ipi_data+0x190/0x1a0 [kvm][] __kvm_io_bus_write+0xa4/0xe8 [kvm][] kvm_io_bus_write+0x54/0x90 [kvm][] kvm_emu_iocsr+0x180/0x310 [kvm][] kvm_handle_gspr+0x280/0x478 [kvm][] kvm_handle_exit+0xc0/0x130 [kvm]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNPWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UCvia a forced variable MTRR range.In most KVM-based setups, legacy devices such as the HPET and TPM areenumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, andoptionally a SystemMemory descriptor for an OperationRegion, e.g. if thedevice needs to be accessed via a Control Method.If a SystemMemory entry is present, then the kernel's ACPI driver willauto-ioremap the region so that it can be accessed at will. However, theACPI spec doesn't provide a way to enumerate the memory type ofSystemMemory regions, i.e. there's no way to tell software that a regionmust be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver alwaysmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.The dedicated device drivers however, e.g. the HPET driver and TPM driver,want to map their associated memory as UC or WC, as accessing PCI devicesusing WB is unsupported.On bare metal and non-CoCO, the conflicting requirements "work" as firmwareconfigures the PCI hole (and other device memory) to be UC in the MTRRs.So even though the ACPI mappings request WB, they are forced to UC- in thekernel's tracking due to the kernel properly handling the MTRR overrides,and thus are compatible with the drivers' requested WC/UC-.With force WB MTRRs on SNP and TDX guests, the ACPI mappings get theirrequested WB if the ACPI mappings are established before the dedicateddriver code attempts to initialize the device. E.g. if acpi_init()runs before the corresponding device driver is probed, ACPI's WB mappingwill "win", and result in the driver's ioremap() failing because theexisting WB mapping isn't compatible with the requested WC/UC-.E.g. when a TPM is emulated by the hypervisor (ignoring the securityimplications of relying on what is allegedly an untrusted entity to storemeasurements), the TPM driver will request UC and fail: [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12Note, the '0x2' and '0x0' values refer to "enum page_cache_mode", not x86'smemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).E.g. tracing mapping requests for TPM TIS yields: Mapping TPM TIS with req_type = 0 WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 Modules linked in: CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460 __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:pidfs: validate extensible ioctlsValidate extensible ioctls stricter than we do now.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smb/server: fix possible memory leak in smb2_read()Memory leak occurs when ksmbd_vfs_read() fails.Fix this by adding the missing kvfree().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: AIDE is an advanced intrusion detection environment. From versions 0.13 to 0.19.1, there is a null pointer dereference vulnerability in AIDE. An attacker can crash the program during report printing or database listing after setting extended file attributes with an empty attribute value or with a key containing a comma. A local user might exploit this to cause a local denial of service. This issue has been patched in version 0.19.2. A workaround involves removing xattrs group from rules matching files on affected file systems.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
aide > 0-0 (version in image is 0.18.8-160000.2.2).
Description: A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Add devm release action to safely tear down CTWhen a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATEflag, the driver initiates TLB invalidation requests via the CTB mechanismwhile releasing the BO. However a premature release of the CTB BO can leadto system crashes, as observed in:Oops: Oops: 0000 [#1] SMP NOPTIRIP: 0010:h2g_write+0x2f3/0x7c0 [xe]Call Trace: guc_ct_send_locked+0x8b/0x670 [xe] xe_guc_ct_send_locked+0x19/0x60 [xe] send_tlb_invalidation+0xb4/0x460 [xe] xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe] ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe] ggtt_node_remove+0x110/0x140 [xe] xe_ggtt_node_remove+0x40/0xa0 [xe] xe_ggtt_remove_bo+0x87/0x250 [xe]Introduce a devm-managed release action during xe_guc_ct_init() andxe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement beforeresource deallocation, preventing the use-after-free scenario.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_extWhen alloc_slab_obj_exts() fails and then later succeeds in allocating aslab extension vector, it calls handle_failed_objexts_alloc() to mark allobjects in the vector as empty. As a result all objects in this slab(slabA) will have their extensions set to CODETAG_EMPTY.Later on if this slabA is used to allocate a slabobj_ext vector foranother slab (slabB), we end up with the slabB->obj_exts pointing to aslabobj_ext vector that itself has a non-NULL slabobj_ext equal toCODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called tofree slabB->obj_exts vector. free_slab_obj_exts() calls mark_objexts_empty(slabB->obj_exts) which willgenerate a warning because it expects slabobj_ext vectors to have a NULLobj_ext, not CODETAG_EMPTY.Modify mark_objexts_empty() to skip the warning and setting the obj_extvalue if it's already set to CODETAG_EMPTY.To quickly detect this WARN, I modified the code fromWARN_ON(slab_exts[offs].ref.ct) to BUG_ON(slab_exts[offs].ref.ct == 1);We then obtained this message:[21630.898561] ------------[ cut here ]------------[21630.898596] kernel BUG at mm/slub.c:2050![21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject][21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: loaded Tainted: G W 6.18.0-rc1+ #74 PREEMPT(voluntary)[21630.910495] Tainted: [W]=WARN[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[21630.912392] pc : __free_slab+0x228/0x250[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : ffff8000a02f73e0[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: ffff0000c0011c40[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: ffff000102199b40[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: ffff70001405ee66[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : ffff800080a295dc[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001[21630.921810] Call trace:[21630.922130] __free_slab+0x228/0x250 (P)[21630.922669] free_slab+0x38/0x118[21630.923079] free_to_partial_list+0x1d4/0x340[21630.923591] __slab_free+0x24c/0x348[21630.924024] ___cache_free+0xf0/0x110[21630.924468] qlist_free_all+0x78/0x130[21630.924922] kasan_quarantine_reduce+0x11---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netconsole: Acquire su_mutex before navigating configs hierarchyThere is a race between operations that iterate over the userdatacg_children list and concurrent add/remove of userdata items throughconfigfs. The update_userdata() function iterates over thent->userdata_group.cg_children list, and count_extradata_entries() alsoiterates over this same list to count nodes.Quoting from Documentation/filesystems/configfs.rst:> A subsystem can navigate the cg_children list and the ci_parent pointer> to see the tree created by the subsystem. This can race with configfs'> management of the hierarchy, so configfs uses the subsystem mutex to> protect modifications. Whenever a subsystem wants to navigate the> hierarchy, it must do so under the protection of the subsystem> mutex.Without proper locking, if a userdata item is added or removedconcurrently while these functions are iterating, the list can beaccessed in an inconsistent state. For example, the list_for_each() loopcan reach a node that is being removed from the list by list_del_init()which sets the nodes' .next pointer to point to itself, so the loop willnever end (or reach the WARN_ON_ONCE in update_userdata() ).Fix this by holding the configfs subsystem mutex (su_mutex) during alloperations that iterate over cg_children.This includes:- userdatum_value_store() which calls update_userdata() to iterate over cg_children- All sysdata_*_enabled_store() functions which call count_extradata_entries() to iterate over cg_childrenThe su_mutex must be acquired before dynamic_netconsole_mutex to avoidpotential lock ordering issues, as configfs operations may already holdsu_mutex when calling into our code.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Initialize allocated memory before useKMSAN reports: Multiple uninitialized values detected:- KMSAN: uninit-value in ntfs_read_hdr (3)- KMSAN: uninit-value in bcmp (3)Memory is allocated by __getname(), which is a wrapper forkmem_cache_alloc(). This memory is used before being properlycleared. Change kmem_cache_alloc() to kmem_cache_zalloc() toproperly allocate and clear memory before use.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: Fix uninit buffer allocated by __getname()Fix uninit errors caused after buffer allocation given to 'de'; byinitializing the buffer with zeroes. The fix was found by using KMSAN.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: fix uninit memory after failed mi_read in mi_format_newFix a KMSAN un-init bug found by syzkaller.ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not beuptodate. We do not bring the buffer uptodate before setting it asuptodate. If the buffer were to not be uptodate, it could mean adding abuffer with un-init data to the mi record. Attempting to load that recordwill trigger KMSAN.Avoid this by setting the buffer as uptodate, if it's not already, byoverwriting it.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()Don't add BO to the vdev->bo_list in ivpu_gem_create_object().When failure happens inside drm_gem_shmem_create(), the BO is notfully created and ivpu_gem_bo_free() callback will not be calledcausing a deleted BO to be left on the list.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: An issue was discovered in Binutils before 2.46. The objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed debug information. A logic flaw in the handling of DWARF location list headers can cause objdump to enter an unbounded loop and produce endless output until manually interrupted. This issue affects versions prior to the upstream fix and allows a local attacker to cause excessive resource consumption by supplying a malicious input file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug_rnglists data. A logic error in the handling of the debug_rnglists header can cause objdump to repeatedly print the same warning message and fail to terminate, resulting in an unbounded logging loop until the process is interrupted. The issue was observed in binutils 2.44. A local attacker can exploit this vulnerability by supplying a malicious input file, leading to excessive CPU and I/O usage and preventing completion of the objdump analysis.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF loclists data. A logic flaw in the DWARF parsing code can cause readelf to repeatedly print the same table output without making forward progress, resulting in an unbounded output loop that never terminates unless externally interrupted. A local attacker can trigger this behavior by supplying a malicious input file, causing excessive CPU and I/O usage and preventing readelf from completing its analysis.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: GNU Binutils thru 2.45.1 readelf contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF .debug_rnglists data. A logic flaw in the DWARF parsing path causes readelf to repeatedly print the same warning message without making forward progress, resulting in a non-terminating output loop that requires manual interruption. No evidence of memory corruption or code execution was observed.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:shmem: fix recovery on rename failuresmaple_tree insertions can fail if we are seriously short on memory;simple_offset_rename() does not recover well if it runs into that.The same goes for simple_offset_rename_exchange().Moreover, shmem_whiteout() expects that if it succeeds, the caller willprogress to d_move(), i.e. that shmem_rename2() won't fail past thesuccessful call of shmem_whiteout().Not hard to fix, fortunately - mtree_store() can't fail if the index weare trying to store into is already present in the tree as a singleton.For simple_offset_rename_exchange() that's enough - we just need to becareful about the order of operations.For simple_offset_rename() solution is to preinsert the target into thetree for new_dir; the rest can be done without any potentially failingoperations.That preinsertion has to be done in shmem_rename2() rather than insimple_offset_rename() itself - otherwise we'd need to deal with thepossibility of failure after successful shmem_whiteout().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Discard Beacon frames to non-broadcast addressBeacon frames are required to be sent to the broadcast address, see IEEEStd 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frameshall be set to the broadcast address"). A unicast Beacon frame might beused as a targeted attack to get one of the associated STAs to dosomething (e.g., using CSA to move it to another channel). As such, itis better have strict filtering for this on the received side anddiscard all Beacon frames that are sent to an unexpected address.This is even more important for cases where beacon protection is used.The current implementation in mac80211 is correctly discarding unicastBeacon frames if the Protected Frame bit in the Frame Control field isset to 0. However, if that bit is set to 1, the logic used for checkingfor configured BIGTK(s) does not actually work. If the driver does nothave logic for dropping unicast Beacon frames with Protected Frame bit1, these frames would be accepted in mac80211 processing as valid Beaconframes even though they are not protected. This would allow beaconprotection to be bypassed. While the logic for checking beaconprotection could be extended to cover this corner case, a more genericcheck for discard all Beacon frames based on A1=unicast address coversthis without needing additional changes.Address all these issues by dropping received Beacon frames if they aresent to a non-broadcast address.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:counter: interrupt-cnt: Drop IRQF_NO_THREAD flagAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, asCONFIG_PROVE_RAW_LOCK_NESTING warns:=============================[ BUG: Invalid wait context ]6.18.0-rc1+git... #1-----------------------------some-user-space-process/1251 is trying to lock:(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]other info that might help us debug this:context-{2:2}no locks held by some-user-space-process/....stack backtrace:CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPTCall trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq... and Sebastian correctly points out. Remove IRQF_NO_THREAD as analternative to switching to raw_spinlock_t, because the latter would limitall potential nested locks to raw_spinlock_t only.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't WARN for connections on invalid channelsIt's not clear (to me) how exactly syzbot managed to hit this,but it seems conceivable that e.g. regulatory changed and hasdisabled a channel between scanning (channel is checked to beusable by cfg80211_get_ies_channel_number) and connecting onthe channel later.With one scenario that isn't covered elsewhere described above,the warning isn't good, replace it with a (more informative)error message.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in NetworkManager. The NetworkManager package allows access to files that may belong to other users. NetworkManager allows non-root users to configure the system's network. The daemon runs with root privileges and can access files owned by users different from the one who added the connection.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
NetworkManager > 0-0 (version in image is 1.52.0-160000.3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollbackoctep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set toioq_vector. If request_irq() fails part-way, the rollback loop callsfree_irq() with dev_id set to 'oct', which does not match the originaldev_id and may leave the irqaction registered.This can keep IRQ handlers alive while ioq_vector is later freed duringunwind/teardown, leading to a use-after-free or crash when an interruptfires.Fix the error path to free IRQs with the same ioq_vector dev_id usedduring request_irq().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In esd_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inesd_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in esd_usb_close().Fix the memory leak by anchoring the URB in theesd_usb_read_bulk_callback() to the dev->rx_submitted anchor.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()Memory allocated for struct vscsiblk_info in scsiback_probe() is notfreed in scsiback_remove() leading to potential memory leaks on remove,as well as in the scsiback_probe() error paths. Fix that by freeing itin scsiback_remove().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Make the addrs_lock be per portMake the addrs_lock be per port, not per ipvlan dev.Initial code seems to be written in the assumption,that any address change must occur under RTNL.But it is not so for the case of IPv6. So1) Introduce per-port addrs_lock.2) It was needed to fix places where it was forgottento take lock (ipvlan_open/ipvlan_close)This appears to be a very minor problem though.Since it's highly unlikely that ipvlan_add_addr() willbe called on 2 CPU simultaneously. But nevertheless,this could cause:1) False-negative of ipvlan_addr_busy(): one interfaceiterated through all port->ipvlans + ipvlan->addrsunder some ipvlan spinlock, and another added IPunder its own lock. Though this is only possiblefor IPv6, since looks like only ipvlan_addr6_event() can becalled without rtnl_lock.2) Race since ipvlan_ht_addr_add(port) is called underdifferent ipvlan->addrs_lock locksThis should not affect performance, since add/remove IPis a rare situation and spinlock is not taken on fastpaths.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loopCurrently this is checked before running the pending work. Normally thisis quite fine, as work items either end up blocking (which will create anew worker for other items), or they complete fairly quickly. But syzbotreports an issue where io-wq takes seemingly forever to exit, and with abit of debugging, this turns out to be because it queues a bunch of big(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn'tsupport ->read_iter(), loop_rw_iter() ends up handling them. Each readreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch ofthese pending, processing the whole chain can take a long time. Easilylonger than the syzbot uninterruptible sleep timeout of 140 seconds.This then triggers a complaint off the io-wq exit path:INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa02738f749RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000caRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98There's really nothing wrong here, outside of processing these readswill take a LONG time. However, we can speed up the exit by checking theIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot willexit the ring after queueing up all of these reads. Then once the firstitem is processed, io-wq will simply cancel the rest. That should avoidsyzbot running into this complaint again.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: ptrace: Fix SVE writes on !SME systemsWhen SVE is supported but SME is not supported, a ptrace write to theNT_ARM_SVE regset can place the tracee into an invalid state where(non-streaming) SVE register data is stored in FP_STATE_SVE format butTIF_SVE is clear. This can result in a later warning fromfpsimd_restore_current_state(), e.g. WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748When this happens, fpsimd_restore_current_state() will set TIF_SVE,placing the task into the correct state. This occurs before any othercheck of TIF_SVE can possibly occur, as other checks of TIF_SVE onlyhappen while the FPSIMD/SVE/SME state is live. Thus, aside from thewarning, there is no functional issue.This bug was introduced during rework to error handling in commit: 9f8bf718f2923 ("arm64/fpsimd: ptrace: Gracefully handle errors")... where the setting of TIF_SVE was moved into a block which is onlyexecuted when system_supports_sme() is true.Fix this by removing the system_supports_sme() check. This ensures thatTIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost ofunconditionally manipulating the tracee's saved svcr value. Themanipulation of svcr is benign and inexpensive, and we already dosimilar elsewhere (e.g. during signal handling), so I don't think it'sworth guarding this with system_supports_sme() checks.Aside from the above, there is no functional change. The 'type' argumentto sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) whensystem_supports_sme(), so the ARM64_VEC_SME case in the switch statementis still unreachable when !system_supports_sme(). WhenCONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(),and the compiler can constant-fold for the case where type isARM64_VEC_SVE, removing the logic for other cases.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix data-race warning and potential load/store tearingFix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packetwhich is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds();and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;The lockless accesses to these to values aren't actually a problem as theread only needs an approximate time of last transmission for the purposesof deciding whether or not the transmission of a keepalive packet iswarranted yet.Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bitarch.Fix both of these by switching to an unsigned int for ->last_tx_at and onlystoring the LSW of the time64_t. It can then be reconstructed at needprovided no more than 68 years has elapsed since the last transmission.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: avoid one data-race in l2tp_tunnel_del_work()We should read sk->sk_socket only when dealing with kernel sockets.syzbot reported the following data-race:BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_releasewrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246value changed: 0xffff88811b818000 -> 0x0000000000000000
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: annotate data-race in ndisc_router_discovery()syzbot found that ndisc_router_discovery() could read and writein6_dev->ra_mtu without holding a lock [1]This looks fine, IFLA_INET6_RA_MTU is best effort.Add READ_ONCE()/WRITE_ONCE() to document the race.Note that we might also reject illegal MTU values(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.[1]BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discoveryread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79...value changed: 0x00000000 -> 0xe5400659
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INITA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH keyinitialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127The issue is triggered when sctp_auth_asoc_init_active_key() fails insctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, thecommand sequence is currently:- SCTP_CMD_PEER_INIT- SCTP_CMD_TIMER_STOP (T1_INIT)- SCTP_CMD_TIMER_START (T1_COOKIE)- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)- SCTP_CMD_ASSOC_SHKEY- SCTP_CMD_GEN_COOKIE_ECHOIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, whileasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set bySCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULLto be queued by sctp_datamsg_from_user().Since command interpretation stops on failure, no COOKIE_ECHO should beensent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has alreadybeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. Asa result, the DATA chunk can be transmitted together with the COOKIE_ECHOin sctp_outq_flush_data(), leading to the observed issue.Similar to the other places where it calls sctp_auth_asoc_init_active_key()right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEYimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and startingT1_COOKIE. This ensures that if shared key generation fails, authenticatedDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,giving the client another chance to process INIT_ACK and retry key setup.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add recursion protection in kernel stack trace recordingA bug was reported about an infinite recursion caused by tracing the rcuevents with the kernel stack trace trigger enabled. The stack trace codecalled back into RCU which then called the stack trace again.Expand the ftrace recursion protection to add a set of bits to protectevents from recursion. Each bit represents the context that the event isin (normal, softirq, interrupt and NMI).Have the stack trace code use the interrupt context to protect againstrecursion.Note, the bug showed an issue in both the RCU code as well as the tracingstacktrace code. This only handles the tracing stack trace side of thebug. The RCU fix will be handled separately.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Subtract size of xdp_frame from allowed metadata sizeThe xdp_frame structure takes up part of the XDP frame headroom,limiting the size of the metadata. However, in bpf_test_run, we don'ttake this into account, which makes it possible for userspace to supplya metadata size that is too large (taking up the entire headroom).If userspace supplies such a large metadata size in live packet mode,the xdp_update_frame_from_buff() call in xdp_test_run_init_page() callwill fail, after which packet transmission proceeds with anuninitialised frame structure, leading to the usual Bad Stuff.The commit in the Fixes tag fixed a related bug where the second checkin xdp_update_frame_from_buff() could fail, but did not add anyadditional constraints on the metadata size. Complete the fix by addingan additional check on the metadata size. Reorder the checks slightly tomake the logic clearer and add a comment.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Fix memory leak in octep_device_setup()In octep_device_setup(), if octep_ctrl_net_init() fails, the functionreturns directly without unmapping the mapped resources and freeing theallocated configuration memory.Fix this by jumping to the unsupported_dev label, which performs thenecessary cleanup. This aligns with the error handling logic of otherpaths in this function.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rocker: fix memory leak in rocker_world_port_post_fini()In rocker_world_port_pre_init(), rocker_port->wpriv is allocated withkzalloc(wops->port_priv_size, GFP_KERNEL). However, inrocker_world_port_post_fini(), the memory is only freed whenwops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);Since rocker_ofdpa_ops does not implement port_post_fini callback(it is NULL), the wpriv memory allocated for each port is never freedwhen ports are removed. This leads to a memory leak ofsizeof(struct ofdpa_port) bytes per port on every device removal.Fix this by always calling kfree(rocker_port->wpriv) regardless ofwhether the port_post_fini callback exists.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:flex_proportions: make fprop_new_period() hardirq safeBernd has reported a lockdep splat from flexible proportions code that isessentially complaining about the following race:run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - sees odd sequence so loops indefinitelyNote that a deadlock like this is only possible if the bdi has configuredmaximum fraction of writeout throughput which is very rare in general butfrequent for example for FUSE bdis. To fix this problem we have to makesure write section of the sequence counter is irqsafe.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domainsFix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix oops due to invalid pointer for kfree() in parse_longname()This fixes a kernel oops when reading ceph snapshot directories (.snap),for example by simply running `ls /mnt/my_ceph/.snap`.The variable str is guarded by __free(kfree), but advanced by one forskipping the initial '_' in snapshot names. Thus, kfree() is calledwith an invalid pointer. This patch removes the need for advancing thepointer so kfree() is called with correct memory pointer.Steps to reproduce:1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)2. Add cephfs mount to fstab$ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" >> /etc/fstab3. Reboot the system$ systemctl reboot4. Check if it's really mounted$ mount | grep stuff5. List snapshots (expected 63 snapshots on my system)$ ls /mnt/test/stuff/.snapNow ls hangs forever and the kernel log shows the oops.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bonding: annotate data-races around slave->last_rxslave->last_rx and slave->target_last_arp_rx[...] can be read and writtenlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.syzbot reported:BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validatewrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410...write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline]...value changed: 0x0000000100005365 -> 0x0000000100005366
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmware: Fix hypercall clobbersFedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ...because the QEMU VMware mouse emulation is buggy, and clears the top 32bits of %rdi that the kernel kept a pointer in.The QEMU vmmouse driver saves and restores the register state in a"uint32_t data[6];" and as a result restores the state with the highbits all cleared.RDI originally contained the value of a valid kernel stack address(0xff5eeb3240003e54). After the vmware hypercall it now contains0x40003e54, and we get a page fault as a result when it is dereferenced.The proper fix would be in QEMU, but this works around the issue in thekernel to keep old setups working, when old kernels had not happened tokeep any state in %rdi over the hypercall.In theory this same issue exists for all the hypercalls in the vmmousedriver; in practice it has only been seen with vmware_hypercall3() andvmware_hypercall4(). For now, just mark RDI/RSI as clobbered for thosetwo calls. This should have a minimal effect on code generation overallas it should be rare for the compiler to want to make RDI/RSI liveacross hypercalls.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()In iscsit_dec_conn_usage_count(), the function calls complete() whileholding the conn->conn_usage_lock. As soon as complete() is invoked, thewaiter (such as iscsit_close_connection()) may wake up and proceed to freethe iscsit_conn structure.If the waiter frees the memory before the current thread reachesspin_unlock_bh(), it results in a KASAN slab-use-after-free as the functionattempts to release a lock within the already-freed connection structure.Fix this by releasing the spinlock before calling complete().
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix potential NULL pointer dereference in header processingIf siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(),qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data()dereferences qp->rx_fpdu->more_ddp_segs without checking, whichmay lead to a NULL pointer deref. Only check more_ddp_segs whenrx_fpdu is present.KASAN splat:[ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7][ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: check for deleted cursors when revalidating two btreesThe free space and inode btree repair functions will rebuild both btreesat the same time, after which it needs to evaluate both btrees toconfirm that the corruptions are gone.However, Jiaming Zhang ran syzbot and produced a crash in the secondxchk_allocbt call. His root-cause analysis is as follows (with minorcorrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree().So. The bnobt revalidation failed on a cross-reference attempt, so wedeleted the cntbt cursor, and then crashed when we tried to revalidatethe cntbt. Therefore, check for a null cntbt cursor before thatrevalidation, and mark the repair incomplete. Also we can ignore thesecond tree entirely if the first tree was rebuilt but is alreadycorrupt.Apply the same fix to xrep_revalidate_iallocbt because it has the sameproblem.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: check return value of xchk_scrub_create_subordFix this function to return NULL instead of a mangled ENOMEM, then fixthe callers to actually check for a null pointer and return ENOMEM.Most of the corrections here are for code merged between 6.2 and 6.10.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: only call xf{array,blob}_destroy if we have a valid pointerOnly call the xfarray and xfblob destructor if we have a valid pointer,and be sure to null out that pointer afterwards. Note that this patchfixes a large number of commits, most of which were merged between 6.9and 6.10.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: get rid of the xchk_xfile_*_descr callsThe xchk_xfile_*_descr macros call kasprintf, which can fail to allocatememory if the formatted string is larger than 16 bytes (or whatever thenofail guarantees are nowadays). Some of them could easily exceed that,and Jiaming Zhang found a few places where that can happen with syzbot.The descriptions are debugging aids and aren't required to be unique, solet's just pass in static strings and eliminate this path to failure.Note this patch touches a number of commits, most of which were mergedbetween 6.6 and 6.14.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: gro: fix outer network offsetThe udp GRO complete stage assumes that all the packets inserted the RXhave the `encapsulation` flag zeroed. Such assumption is not true, as afew H/W NICs can set such flag when H/W offloading the checksum foran UDP encapsulated traffic, the tun driver can inject GSO packets withUDP encapsulation and the problematic layout can also be created viaa veth based setup.Due to the above, in the problematic scenarios, udp4_gro_complete() usesthe wrong network offset (inner instead of outer) to compute the outerUDP header pseudo checksum, leading to csum validation errors later onin packet processing.Address the issue always clearing the encapsulation flag at GRO completiontime. Such flag will be set again as needed for encapsulated packets byudp_gro_complete().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Compile tested only. Issue found using code review.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Also, decrement i in the devlink_alloc failure path to point to thelast successfully allocated index.Compile tested only. Issue found using code review.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocksAs Paolo said earlier [1]:"Since the blamed commit below, classify can return TC_ACT_CONSUMED whilethe current skb being held by the defragmentation engine. As reported byGangMin Kim, if such packet is that may cause a UaF when the defrag enginelater on tries to tuch again such packet."act_ct was never meant to be used in the egress path, however some usersare attaching it to egress today [2]. Attempting to reach a middleground, we noticed that, while most qdiscs are not handlingTC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, weaddress the issue by only allowing act_ct to bind to clsact/ingressqdiscs and shared blocks. That way it's still possible to attach act_ct toegress (albeit only with clsact).[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/[2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()Fix a user triggerable leak on the system call failure path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Fix cred ref leak in nfsd_nl_threads_set_doit().syzbot reported memory leak of struct cred. [0]nfsd_nl_threads_set_doit() passes get_current_cred() tonfsd_svc(), but put_cred() is not called after that.The cred is finally passed down to _svc_xprt_create(),which calls get_cred() with the cred for struct svc_xprt.The ownership of the refcount by get_current_cred() is nottransferred to anywhere and is just leaked.nfsd_svc() is also called from write_threads(), but it doesnot bump file->f_cred there.nfsd_nl_threads_set_doit() is called from sendmsg() andcurrent->cred does not go away.Let's use current_cred() in nfsd_nl_threads_set_doit().[0]:BUG: memory leakunreferenced object 0xffff888108b89480 (size 184): comm "syz-executor", pid 5994, jiffies 4294943386 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 369454a7): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c:5270 prepare_creds+0x22/0x600 kernel/cred.c:185 copy_creds+0x44/0x290 kernel/cred.c:286 copy_process+0x7a7/0x2870 kernel/fork.c:2086 kernel_clone+0xac/0x6e0 kernel/fork.c:2651 __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate data-races around sk->sk_{data_ready,write_space}skmsg (and probably other layers) are changing these pointerswhile other cpus might read them concurrently.Add corresponding READ_ONCE()/WRITE_ONCE() annotationsfor UDP, TCP and AF_UNIX.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Don't log plaintext credentials in cifs_set_cifscredsWhen debug logging is enabled, cifs_set_cifscreds() logs the keypayload and exposes the plaintext username and password. Remove thedebug log to avoid exposing credentials.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix preempt count leak in napi poll tracepointUsing get_cpu() in the tracepoint assignment causes an obvious preemptcount leak because nothing invokes put_cpu() to undo it: softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?This clearly has seen a lot of testing in the last 3+ years...Use smp_processor_id() instead.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix ARM64 alignment fault in multipath hash seed`struct sysctl_fib_multipath_hash_seed` contains two u32 fields(user_seed and mp_seed), making it an 8-byte structure with a 4-bytealignment requirement.In `fib_multipath_hash_from_keys()`, the code evaluates the entirestruct atomically via `READ_ONCE()`: mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;While this silently works on GCC by falling back to unaligned regularloads which the ARM64 kernel tolerates, it causes a fatal kernel panicwhen compiled with Clang and LTO enabled.Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquirewhen CONFIG_LTO=y") strengthens `READ_ONCE()` to use Load-Acquireinstructions (`ldar` / `ldapr`) to prevent compiler reordering bugsunder Clang LTO. Since the macro evaluates the full 8-byte struct,Clang emits a 64-bit `ldar` instruction. ARM64 architecture strictlyrequires `ldar` to be naturally aligned, thus executing it on a 4-bytealigned address triggers a strict Alignment Fault (FSC = 0x21).Fix the read side by moving the `READ_ONCE()` directly to the `u32`member, which emits a safe 32-bit `ldar Wn`.Furthermore, Eric Dumazet pointed out that `WRITE_ONCE()` on the entirestruct in `proc_fib_multipath_hash_set_seed()` is also flawed. Analysisshows that Clang splits this 8-byte write into two separate 32-bit`str` instructions. While this avoids an alignment fault, it destroysatomicity and exposes a tear-write vulnerability. Fix this byexplicitly splitting the write into two 32-bit `WRITE_ONCE()`operations.Finally, add the missing `READ_ONCE()` when reading `user_seed` in`proc_fib_multipath_hash_seed()` to ensure proper pairing andconcurrency safety.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix fragment node deletion to prevent buffer leakAfter commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"),the list_node field is reused for both the xskb pool list and the bufferfree list, this causes a buffer leak as described below.xp_free() checks if a buffer is already on the free list usinglist_empty(&xskb->list_node). When list_del() is used to remove a nodefrom the xskb pool list, it doesn't reinitialize the node pointers.This means list_empty() will return false even after the node has beenremoved, causing xp_free() to incorrectly skip adding the buffer to thefree list.Fix this by using list_del_init() instead of list_del() in all fragmenthandling paths, this ensures the list node is reinitialized after removal,allowing the list_empty() to work correctly.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: io: Extract user memory type in ioremap_prot()The only caller of ioremap_prot() outside of the generic ioremap()implementation is generic_access_phys(), which passes a 'pgprot_t' valuedetermined from the user mapping of the target 'pfn' being accessed bythe kernel. On arm64, the 'pgprot_t' contains all of the non-addressbits from the pte, including the permission controls, and so we end upreturning a new user mapping from ioremap_prot() which faults whenaccessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68Extract only the memory type from the user 'pgprot_t' in ioremap_prot()and assert that we're being passed a user mapping, to protect us againstany changes in future that may require additional handling. To avoidfalsely flagging users of ioremap(), provide our own ioremap() macrowhich simply wraps __ioremap_prot().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix race of nvdimm_bus object when creating nvdimm objectsFound issue during running of cxl-translate.sh unit test. Adding a 3ssleep right before the test seems to make the issue reproduce fairlyconsistently. The cxl_translate module has dependency on cxl_acpi andcauses orphaned nvdimm objects to reprobe after cxl_acpi is removed.The nvdimm_bus object is registered by the cxl_nvb object whencxl_acpi_probe() is called. With the nvdimm_bus object missing,__nd_device_register() will trigger NULL pointer dereference whenaccessing the dev->parent that points to &nvdimm_bus->dev.[ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c[ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025[ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core][ 192.899459] RIP: 0010:kobject_get+0xc/0x90[ 192.924871] Call Trace:[ 192.925959] [ 192.926976] ? pm_runtime_init+0xb9/0xe0[ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm][ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm][ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem][ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core][ 192.943349] really_probe+0xde/0x380This patch also relies on the previous change wheredevm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c insteadof drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called.2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe().3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY.The removal of cxl_nvdimm devices should prevent any orphaned devicesfrom probing once the nvdimm_bus is gone.[ dj: Fixed 0-day reported kdoc issue. ][ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: split gc into unlink and reclaim phaseYiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service).We must split GC in an unlink and a reclaim phase.We cannot queue elements for freeing until pointers have been swapped.Expired elements are still exposed to both the packet path and userspacedumpers via the live copy of the data structure.call_rcu() does not protect us: dump operations or element lookups startingafter call_rcu has fired can still observe the free'd element, unless thecommit phase has made enough progress to swap the clone and live pointersbefore any new reader has picked up the old version.This a similar approach as done recently for the rbtree backend in commit35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert").
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Correct speculative safety in fred_extint()array_index_nospec() is no use if the result gets spilled to the stack, asit makes the believed safe-under-speculation value subject to memorypredictions.For all practical purposes, this means array_index_nospec() must be used inthe expression that accesses the array.As the code currently stands, it's the wrong side of irqentry_enter(), and'index' is put into %ebp across the function call.Remove the index variable and reposition array_index_nospec(), so it'scalculated immediately before the array access.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: register phy led_triggers during probe to avoid AB-BA deadlockThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV andLED_TRIGGER_PHY are enabled:[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock);[ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234[ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c[ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c[ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0[ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0[ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c[ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78[ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock "rtnl_mutex" by calling rtnl_lock();[ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0[ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c[ 1362.104022] [<80014504>] syscall_common+0x34/0x58Here LED_TRIGGER_PHY is registering LED triggers during phy_attachwhile holding RTNL and then taking triggers_list_lock.[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock "rtnl_mutex" via rtnl_lock();[ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4[ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock);[ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c[ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc[ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c[ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4[ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c[ 1362.232164] [<80014504>] syscall_common+0x34/0x58Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takestriggers_list_lock and then RTNL. A classical AB-BA deadlock.phy_led_triggers_registers() does not require the RTNL, it does notmake any calls into the network stack which require protection. Thereis also no requirement the PHY has been attached to a MAC, thetriggers only make use of phydev state. This allows the call tophy_led_triggers_registers() to be placed elsewhere. PHY probe() andrelease() don't hold RTNL, so solving the AB-BA deadlock.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm: thp: deny THP for files on anonymous inodesfile_thp_enabled() incorrectly allows THP for files on anonymous inodes(e.g. guest_memfd and secretmem). These files are created viaalloc_file_pseudo(), which does not call get_write_access() and leavesinode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) beingtrue, they appear as read-only regular files whenCONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THPcollapse.Anonymous inodes can never pass the inode_is_open_for_write() checksince their i_writecount is never incremented through the normal VFSopen path. The right thing to do is to exclude them from THP eligibilityaltogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for realfilesystem files (e.g. shared libraries), not for pseudo-filesysteminodes.For guest_memfd, this allows khugepaged and MADV_COLLAPSE to createlarge folios in the page cache via the collapse path, but theguest_memfd fault handler does not support large folios. This triggersWARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().For secretmem, collapse_file() tries to copy page contents through thedirect map, but secretmem pages are removed from the direct map. Thiscan result in a kernel crash: BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpy_orig+0x16/0x130 Call Trace: collapse_file hpage_collapse_scan_file madvise_collapseSecretmem is not affected by the crash on upstream as the memory failurerecovery handles the failed copy gracefully, but it still triggersconfusing false memory failure reports: Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: RecoveredCheck IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for allanonymous inode files.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fcloop: Check remoteport port_state before calling done callbackIn nvme_fc_handle_ls_rqst_work, the lsrsp->done callback is only set whenremoteport->port_state is FC_OBJSTATE_ONLINE. Otherwise, thenvme_fc_xmt_ls_rsp's LLDD call to lport->ops->xmt_ls_rsp is expected tofail and the nvme-fc transport layer itself will directly callnvme_fc_xmt_ls_rsp_free instead of relying on LLDD's done callback to freethe lsrsp resources.Update the fcloop_t2h_xmt_ls_rsp routine to check remoteport->port_state.If online, then lsrsp->done callback will free the lsrsp. Else, return-ENODEV to signal the nvme-fc transport to handle freeing lsrsp.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ice: change XDP RxQ frag_size from DMA write length to xdp.frame_szThe only user of frag_size field in XDP RxQ info isbpf_xdp_frags_increase_tail(). It clearly expects whole buff size insteadof DMA write size. Different assumptions in ice driver configuration leadto negative tailroom.This allows to trigger kernel panic, when usingXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to6912 and the requested offset to a huge value, e.g.XSK_UMEM__MAX_FRAME_SIZE * 100.Due to other quirks of the ZC configuration in ice, panic is not observedin ZC mode, but tailroom growing still fails when it should not.Use fill queue buffer truesize instead of DMA write size in XDP RxQ info.Fix ZC mode too by using the new helper.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. Then, if neigh_suppress is enabled and an ICMPv6Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() willdereference ipv6_stub->nd_tbl which is NULL, passing it toneigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() inthe callers. This is in essence disabling NS/NA suppression when IPv6 isdisabled.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearingstruct bpf_plt contains a u64 target field. Currently, the BPF JITallocator requests an alignment of 4 bytes (sizeof(u32)) for the JITbuffer.Because the base address of the JIT buffer can be 4-byte aligned (e.g.,ending in 0x4 or 0xc), the relative padding logic in build_plt() failsto ensure that target lands on an 8-byte boundary.This leads to two issues:1. UBSAN reports misaligned-access warnings when dereferencing the structure.2. More critically, target is updated concurrently via WRITE_ONCE() in bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.Fix this by increasing the allocation alignment requirement to 8 bytes(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base ofthe JIT buffer to an 8-byte boundary, allowing the relative padding mathin build_plt() to correctly align the target field.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPLIn DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDAbuffer cleanup path. It iterates num_bufs times and attempts to unmapentries in the dma array.This leads to two issues:1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations.2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings(trace below is how we noticed this issue).UBSAN: array-index-out-of-bounds indrivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out ofrange for type 'dma_addr_t[18]' (aka 'unsigned long long[18]')Workqueue: gve gve_service_task [gve]Call Trace:dump_stack_lvl+0x33/0xa0__ubsan_handle_out_of_bounds+0xdc/0x110gve_tx_stop_ring_dqo+0x182/0x200 [gve]gve_close+0x1be/0x450 [gve]gve_reset+0x99/0x120 [gve]gve_service_task+0x61/0x100 [gve]process_scheduled_works+0x1e9/0x380Fix this by properly checking for QPL mode and delegating togve_free_tx_qpl_bufs() to reclaim the buffers.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix memory leak in ice_set_ringparam()In ice_set_ringparam, tx_rings and xdp_rings are allocated beforerx_rings. If the allocation of rx_rings fails, the code jumps tothe done label leaking both tx_rings and xdp_rings. Furthermore, ifthe setup of an individual Rx ring fails during the loop, the code jumpsto the free_tx label which releases tx_rings but leaks xdp_rings.Fix this by introducing a free_xdp label and updating the error paths toensure both xdp_rings and tx_rings are properly freed if rx_ringsallocation or setup fails.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflowThe dma_map_sg tracepoint can trigger a perf buffer overflow whentracing large scatter-gather lists. With devices like virtio-gpucreating large DRM buffers, nents can exceed 1000 entries, resultingin: phys_addrs: 1000 * 8 bytes = 8,000 bytes dma_addrs: 1000 * 8 bytes = 8,000 bytes lengths: 1000 * 4 bytes = 4,000 bytes Total: ~20,000 bytesThis exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing: WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405 perf buffer not large enough, wanted 24620, have 8192Cap all three dynamic arrays at 128 entries using min() in the arraysize calculation. This ensures arrays are only as large as needed(up to the cap), avoiding unnecessary memory allocation for smalloperations while preventing overflow for large ones.The tracepoint now records the full nents/ents counts and a truncatedflag so users can see when data has been capped.Changes in v2:- Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from Steven Rostedt)- This allocates only what's needed up to the cap, avoiding waste for small operationsReviwed-by: Sean Anderson
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_CT: drop pending enqueued packets on template removalTemplates refer to objects that can go away while packets are sitting innfqueue refer to:- helper, this can be an issue on module removal.- timeout policy, nfnetlink_cttimeout might remove it.The use of templates with zone and event cache filter are safe, sincethis just copies values.Flush these enqueued packets in case the template rule gets removed.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Give up GC if MSG_PEEK intervened.Igor Ushakov reported that GC purged the receive queue ofan alive socket due to a race with MSG_PEEK with a nice repro.This is the exact same issue previously fixed by commitcbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").After GC was replaced with the current algorithm, the citedcommit removed the locking dance in unix_peek_fds() andreintroduced the same issue.The problem is that MSG_PEEK bumps a file refcount withoutinteracting with GC.Consider an SCC containing sk-A and sk-B, where sk-A isclose()d but can be recv()ed via sk-B.The bad thing happens if sk-A is recv()ed with MSG_PEEK fromsk-B and sk-B is close()d while GC is checking unix_vertex_dead()for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> trueInitially, sk-A's file refcount is 1 by the inflight fd in sk-Brecvq. GC thinks sk-A is dead because the file refcount is thesame as the number of its inflight fds.However, sk-A's file refcount is bumped silently by MSG_PEEK,which invalidates the previous evaluation.At this moment, sk-B's file refcount is 2; one by the open fd,and one by the inflight fd in sk-A. The subsequent close()releases one refcount by the former.Finally, GC incorrectly concludes that both sk-A and sk-B are dead.One option is to restore the locking dance in unix_peek_fds(),but we can resolve this more elegantly thanks to the new algorithm.The point is that the issue does not occur without the subsequentclose() and we actually do not need to synchronise MSG_PEEK withthe dead SCC detection.When the issue occurs, close() and GC touch the same file refcount.If GC sees the refcount being decremented by close(), it can justgive up garbage-collecting the SCC.Therefore, we only need to signal the race during MSG_PEEK witha proper memory barrier to make it visible to the GC.Let's use seqcount_t to notify GC when MSG_PEEK occurs and letit defer the SCC to the next run.This way no locking is needed on the MSG_PEEK side, and we canavoid imposing a penalty on every MSG_PEEK unnecessarily.Note that we can retry within unix_scc_dead() if MSG_PEEK isdetected, but we do not do so to avoid hung task splat fromabusive MSG_PEEK calls.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: Fix circular locking dependency in rds_tcp_tunesyzbot reported a circular locking dependency in rds_tcp_tune() wheresk_net_refcnt_upgrade() is called while holding the socket lock:======================================================WARNING: possible circular locking dependency detected======================================================kworker/u10:8/15040 is trying to acquire lock:ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0},at: __kmalloc_cache_noprof+0x4b/0x6f0but task is already holding lock:ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0},at: rds_tcp_tune+0xd7/0x930The issue occurs because sk_net_refcnt_upgrade() performs memoryallocation (via get_net_track() -> ref_tracker_alloc()) while thesocket lock is held, creating a circular dependency with fs_reclaim.Fix this by moving sk_net_refcnt_upgrade() outside the socket lockcritical section. This is safe because the fields modified by thesk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are notaccessed by any concurrent code path at this point.v2: - Corrected fixes tag - check patch line wrap nits - ai commentary nits
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313-requests > 0-0 (version in image is 2.32.4-160000.2.2).
Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()m2sm() converts a u32 slope to a u64 scaled value. For large inputs(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() storesthe difference of two such u64 values in a u32 variable `dsm` anduses it as a divisor. When the difference is exactly 2^32 thetruncation yields zero, causing a divide-by-zero oops in theconcave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...]Widen `dsm` to u64 and replace do_div() with div64_u64() so the fulldifference is preserved.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: skb: fix cross-cache free of KFENCE-allocated skb headSKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2value (e.g. 704 on x86_64) to avoid collisions with generic kmallocbucket sizes. This ensures that skb_kfree_head() can reliably useskb_end_offset to distinguish skb heads allocated fromskb_small_head_cache vs. generic kmalloc caches.However, when KFENCE is enabled, kfence_ksize() returns the exactrequested allocation size instead of the slab bucket size. If a caller(e.g. bpf_test_init) allocates skb head data via kzalloc() and therequested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, thenslab_build_skb() -> ksize() returns that exact value. After subtractingskb_shared_info overhead, skb_end_offset ends up matchingSKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly freethe object to skb_small_head_cache instead of back to the originalkmalloc cache, resulting in a slab cross-cache free: kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1kFix this by always calling kfree(head) in skb_kfree_head(). This keepsthe free path generic and avoids allocator-specific misclassificationfor KFENCE objects.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix crash when the event log is disabledIf reporting errors to the event log is not supported by the hardware,and an error that causes Function Level Reset (FLR) is received, thedriver will try to restore the event log even if it was not allocated.Also, only try to free the event log if it was properly allocated.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free and NULL deref in smb_grant_oplock()smb_grant_oplock() has two issues in the oplock publication sequence:1) opinfo is linked into ci->m_op_list (via opinfo_add) before add_lease_global_list() is called. If add_lease_global_list() fails (kmalloc returns NULL), the error path frees the opinfo via __free_opinfo() while it is still linked in ci->m_op_list. Concurrent m_op_list readers (opinfo_get_list, or direct iteration in smb_break_all_levII_oplock) dereference the freed node.2) opinfo->o_fp is assigned after add_lease_global_list() publishes the opinfo on the global lease list. A concurrent find_same_lease_key() can walk the lease list and dereference opinfo->o_fp->f_ci while o_fp is still NULL.Fix by restructuring the publication sequence to eliminate post-publishfailure:- Set opinfo->o_fp before any list publication (fixes NULL deref).- Preallocate lease_table via alloc_lease_table() before opinfo_add() so add_lease_global_list() becomes infallible after publication.- Keep the original m_op_list publication order (opinfo_add before lease list) so concurrent opens via same_client_has_lease() and opinfo_get_list() still see the in-flight grant.- Use opinfo_put() instead of __free_opinfo() on err_out so that the RCU-deferred free path is used.This also requires splitting add_lease_global_list() to take apreallocated lease_table and changing its return type from int to void,since it can no longer fail.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: reject mount if bigalloc with s_first_data_block != 0bigalloc with s_first_data_block != 0 is not supported, reject mountingit.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid infinite loops caused by residual dataOn the mkdir/mknod path, when mapping logical blocks to physical blocks,if inserting a new extent into the extent tree fails (in this example,because the file system disabled the huge file feature when marking theinode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() toreclaim the physical block without deleting the corresponding data inthe extent tree. This causes subsequent mkdir operations to referencethe previously reclaimed physical block number again, even though thisphysical block is already being used by the xattr block. Therefore, asituation arises where both the directory and xattr are using the samebuffer head block in memory simultaneously.The above causes ext4_xattr_block_set() to enter an infinite loop about"inserted" and cannot release the inode lock, ultimately leading to the143s blocking problem mentioned in [1].If the metadata is corrupted, then trying to remove some extent spacecan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVEwas passed, remove space wrongly update quota information.Jan Kara suggests distinguishing between two cases:1) The error is ENOSPC or EDQUOT - in this case the filesystem is fullyconsistent and we must maintain its consistency including all theaccounting. However these errors can happen only early before we'veinserted the extent into the extent tree. So current code works correctlyfor this case.2) Some other error - this means metadata is corrupted. We should strive todo as few modifications as possible to limit damage. So I'd just skipfreeing of allocated blocks.[1]INFO: task syz.0.17:5995 blocked for more than 143 seconds.Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: validate p_idx bounds in ext4_ext_correct_indexesext4_ext_correct_indexes() walks up the extent tree correctingindex entries when the first extent in a leaf is modified. Beforeaccessing path[k].p_idx->ei_block, there is no validation thatp_idx falls within the valid range of index entries for thatlevel.If the on-disk extent header contains a corrupted or craftedeh_entries value, p_idx can point past the end of the allocatedbuffer, causing a slab-out-of-bounds read.Fix this by validating path[k].p_idx against EXT_LAST_INDEX() atboth access sites: before the while loop and inside it. Return-EFSCORRUPTED if the index pointer is out of range, consistentwith how other bounds violations are handled in the ext4 extenttree code.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: replace BUG_ON with proper error handling in ext4_read_inline_folioReplace BUG_ON() with proper error handling when inline data sizeexceeds PAGE_SIZE. This prevents kernel panic and allows the system tocontinue running while properly reporting the filesystem corruption.The error is logged via ext4_error_inode(), the buffer head is releasedto prevent memory leak, and -EFSCORRUPTED is returned to indicatefilesystem corruption.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: convert inline data to extents when truncate exceeds inline sizeAdd a check in ext4_setattr() to convert files from inline data storageto extent-based storage when truncate() grows the file size beyond theinline capacity. This prevents the filesystem from entering aninconsistent state where the inline data flag is set but the file sizeexceeds what can be stored inline.Without this fix, the following sequence causes a kernel BUG_ON():1. Mount filesystem with inode that has inline flag set and small size2. truncate(file, 50MB) - grows size but inline flag remains set3. sendfile() attempts to write data4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity)The crash occurs because ext4_write_inline_data() expects inline storageto accommodate the write, but the actual inline capacity (~60 bytes fori_block + ~96 bytes for xattrs) is far smaller than the file size andwrite request.The fix checks if the new size from setattr exceeds the inode's actualinline capacity (EXT4_I(inode)->i_inline_size) and converts the file toextent-based storage before proceeding with the size change.This addresses the root cause by ensuring the inline data flag and filesize remain consistent during truncate operations.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: avoid dereferencing log items after push callbacksAfter xfsaild_push_item() calls iop_push(), the log item may have beenfreed if the AIL lock was dropped during the push. Background inodereclaim or the dquot shrinker can free the log item while the AIL lockis not held, and the tracepoints in the switch statement dereferencethe log item after iop_push() returns.Fix this by capturing the log item type, flags, and LSN before callingxfsaild_push_item(), and introducing a new xfs_ail_push_class traceevent class that takes these pre-captured values and the ailp pointerinstead of the log item pointer.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: save ailp before dropping the AIL lock in push callbacksIn xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lockis dropped to perform buffer IO. Once the cluster buffer no longerprotects the log item from reclaim, the log item may be freed bybackground reclaim or the dquot shrinker. The subsequent spin_lock()call dereferences lip->li_ailp, which is a use-after-free.Fix this by saving the ailp pointer in a local variable while the AILlock is held and the log item is guaranteed to be valid.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: stop reclaim before pushing AIL during unmountThe unmount sequence in xfs_unmount_flush_inodes() pushed the AIL whilebackground reclaim and inodegc are still running. This is brokenindependently of any use-after-free issues - background reclaim andinodegc should not be running while the AIL is being pushed duringunmount, as inodegc can dirty and insert inodes into the AIL during theflush, and background reclaim can race to abort and free dirty inodes.Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel backgroundreclaim before pushing the AIL. Stop inodegc before cancellingm_reclaim_work because the inodegc worker can re-queue m_reclaim_workvia xfs_inodegc_set_reclaimable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]Multiple sysfs command paths dereference contexts_arr[0] without firstverifying that kdamond->contexts->nr == 1. A user can set nr_contexts to0 via sysfs while DAMON is running, causing NULL pointer dereferences.In more detail, the issue can be triggered by privileged users likebelow.First, start DAMON and make contexts directory empty(kdamond->contexts->nr == 0). # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/nr_contextsThen, each of below commands will cause the NULL pointer dereference. # echo update_schemes_stats > state # echo update_schemes_tried_regions > state # echo update_schemes_tried_bytes > state # echo update_schemes_effective_quotas > state # echo update_tuned_intervals > stateGuard all commands (except OFF) at the entry point ofdamon_sysfs_handle_cmd().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: do not expire session on binding failureWhen a multichannel session binding request fails (e.g. wrong password),the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED.However, during binding, sess points to the target session looked up viaksmbd_session_lookup_slowpath() -- which belongs to another connection'suser. This allows a remote attacker to invalidate any active session bysimply sending a binding request with a wrong password (DoS).Fix this by skipping session expiration when the failed request wasa binding attempt, since the session does not belong to the currentconnection. The reference taken by ksmbd_session_lookup_slowpath() isstill correctly released via ksmbd_user_session_put().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix memory leaks and NULL deref in smb2_lock()smb2_lock() has three error handling issues after list_del() detachessmb_lock from lock_list at no_check_cl:1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.3) In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to beforethe if(!rc) check in the UNLOCK branch so all exit paths share onefree site, and by freeing smb_lock and flock before goto out in thenon-UNLOCK branch. Propagate the correct error code in both cases.Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and addinga NULL check for locks_free_lock(rlock) in the shared cleanup.Found via call-graph analysis using sqry.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: always keep track of remap prev/nextDuring 3D workload, user is reporting hitting:[ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925[ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)[ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe][ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282[ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000[ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000[ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380[ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380[ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000[ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033[ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0[ 413.362088] PKRU: 55555554[ 413.362089] Call Trace:[ 413.362092] [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe]Which seems to hint that the vma we are re-inserting for the ops unwindis either invalid or overlapping with something already inserted in thevm. It shouldn't be invalid since this is a re-insertion, so must haveworked before. Leaving the likely culprit as something already placedwhere we want to insert the vma.Following from that, for the case where we do something like a rebind inthe middle of a vma, and one or both mapped ends are already compatible,we skip doing the rebind of those vma and set next/prev to NULL. As wellas then adjust the original unmap va range, to avoid unmapping the ends.However, if we trigger the unwind path, we end up with three va, withthe two ends never being removed and the original va range in the middlestill being the shrunken size.If this occurs, one failure mode is when another unwind op needs tointeract with that range, which can happen with a vector of binds. Forexample, if we need to re-insert something in place of the original va.In this case the va is still the shrunken version, so when removing itand then doing a re-insert it can overlap with the ends, which werenever removed, triggering a warning like above, plus leaving the vm in abad state.With that, we need two things here: 1) Stop nuking the prev/next tracking for the skip cases. Instead relying on checking for skip prev/next, where needed. That way on the unwind path, we now correctly remove both ends. 2) Undo the unmap va shrinkage, on the unwind path. With the two ends now removed the unmap va should expand back to the original size again, before re-insertion.v2: - Update the explanation in the commit message, based on an actual IGT of triggering this issue, rather than conjecture. - Also undo the unmap shrinkage, for the skip case. With the two ends now removed, the original unmap va range should expand back to the original range.v3: - Track the old start/range separately. vma_size/start() uses the va info directly.(cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (pmbus/core) Protect regulator operations with mutexThe regulator operations pmbus_regulator_get_voltage(),pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()access PMBus registers and shared data but were not protected bythe update_lock mutex. This could lead to race conditions.However, adding mutex protection directly to these functions causesa deadlock because pmbus_regulator_notify() (which callsregulator_notifier_call_chain()) is often called with the mutexalready held (e.g., from pmbus_fault_handler()). If a regulatorcallback then calls one of the now-protected voltage functions,it will attempt to acquire the same mutex.Rework pmbus_regulator_notify() to utilize a worker function tosend notifications outside of the mutex protection. Events arestored as atomics in a per-page bitmask and processed by the worker.Initialize the worker and its associated data during regulatorregistration, and ensure it is cancelled on device removal usingdevm_add_action_or_reset().While at it, remove the unnecessary include of linux/of.h.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Initialize free_qp completion before using itIn irdma_create_qp, if ib_copy_to_udata fails, it will callirdma_destroy_qp to clean up which will attempt to wait onthe free_qp completion, which is not initialized yet. Fix thisby initializing the completion before the ib_copy_to_udata call.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use netlink policy range checksReplace manual range and mask validations with netlink policyannotations in ctnetlink code paths, so that the netlink core rejectsinvalid values early and can generate extack errors.- CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check.- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks.- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags.Extracted from a broader nf-next patch by Florian Westphal, scoped toctnetlink for the fixes tree.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol createWe have recently observed a number of subvolumes with broken dentries.ls-ing the parent dir looks like:drwxrwxrwt 1 root root 16 Jan 23 16:49 .drwxr-xr-x 1 root root 24 Jan 23 16:48 ..d????????? ? ? ? ? ? broken_subvoland similarly stat-ing the file fails.In this state, deleting the subvol fails with ENOENT, but attempting tocreate a new file or subvol over it errors out with EEXIST and evenaborts the fs. Which leaves us a bit stuck.dmesg contains a single notable error message reading:"could not do orphan cleanup -2"2 is ENOENT and the error comes from the failure handling path ofbtrfs_orphan_cleanup(), with the stack leading back up tobtrfs_lookup().btrfs_lookupbtrfs_lookup_dentrybtrfs_orphan_cleanup // prints that message and returns -ENOENTAfter some detailed inspection of the internal state, it became clearthat:- there are no orphan items for the subvol- the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc.- the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later.- after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want.i.e.,btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolumebtrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)on the root when it runs, so it cannot run more than once on a givenroot, so something else must run concurrently. However, the obviousroutes to deleting an orphan when nlinks goes to 0 should not be able torun without first doing a lookup into the subvolume, which should runbtrfs_orphan_cleanup() and set the bit.The final important observation is that create_subvol() callsd_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so ifthe dentry cache gets dropped, the next lookup into the subvolume willmake a real call into btrfs_orphan_cleanup() for the first time. Thisopens up the possibility of concurrently deleting the inode/orphan itemsbut most typical evict() paths will be holding a reference on the parentdentry (child dentry holds parent->d_lockref.count via dget ind_alloc(), released in __dentry_kill()) and prevent the parent frombeing removed from the dentry cache.The one exception is delayed iputs. Ordered extent creation callsigrab() on the inode. If the file is unlinked and closed while thoserefs are held, iput() in __dentry_kill() decrements i_count but doesnot trigger eviction (i_count > 0). The child dentry is freed and thesubvol dentry's d_lockref.count drops to 0, making it evictable whilethe inode is still alive.Since there are two races (the race between writeback and unlink andthe race between lookup and delayed iputs), and there are too many movingparts, the following three diagrams show the complete picture.(Only the second and third are races)Phase 1:Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP setbtrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix exception exit lock checking for subprogsprocess_bpf_exit_full() passes check_lock = !curframe tocheck_resource_leak(), which is false in cases when bpf_throw() iscalled from a static subprog. This makes check_resource_leak() to skipvalidation of active_rcu_locks, active_preempt_locks, andactive_irq_id on exception exits from subprogs.At runtime bpf_throw() unwinds the stack via ORC without releasing anyuser-acquired locks, which may cause various issues as the result.Fix by setting check_lock = true for exception exits regardless ofcurframe, since exceptions bypass all intermediate framecleanup. Update the error message prefix to "bpf_throw" for exceptionexits to distinguish them from normal BPF_EXIT.Fix reject_subprog_with_rcu_read_lock test which was previouslypassing for the wrong reason. Test program returned directly from thesubprog call without closing the RCU section, so the error wastriggered by the unclosed RCU lock on normal exit, not bybpf_throw. Update __msg annotations for affected tests to match thenew "bpf_throw" error prefix.The spin_lock case is not affected because they are already checked [1]at the call site in do_check_insn() before bpf_throw can run.[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()When querying a nexthop object via RTM_GETNEXTHOP, the kernel currentlyallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient forsingle nexthops and small Equal-Cost Multi-Path groups, this fixedallocation fails for large nexthop groups like 512 nexthops.This results in the following warning splat: WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) 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) Fix this by allocating the size dynamically using nh_nlmsg_size() andusing nlmsg_new(), this is consistent with nexthop_notify() behavior. Inaddition, adjust nh_nlmsg_size_grp() so it calculates the size neededbased on flags passed. While at it, also add the size of NHA_FDB fornexthop group size calculation as it was missing too.This cannot be reproduced via iproute2 as the group size is currentlylimited and the command fails as follows:addattr_l ERROR: message exceeded bound of 1048
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: server: let send_done handle a completion without IB_SEND_SIGNALEDWith smbdirect_send_batch processing we likely have requests withoutIB_SEND_SIGNALED, which will be destroyed in the final requestthat has IB_SEND_SIGNALED set.If the connection is broken all requests are signaledeven without explicit IB_SEND_SIGNALED.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:smb: server: make use of smbdirect_socket.send_io.bcreditsIt turns out that our code will corrupt the stream ofreassabled data transfer messages when we trigger animmendiate (empty) send.In order to fix this we'll have a single 'batch' credit perconnection. And code getting that credit is free to useas much messages until remaining_length reaches 0, thenthe batch credit it given back and the next logical send canhappen.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix missing runtime PM reference in ccs_mode_storeccs_mode_store() calls xe_gt_reset() which internally invokesxe_pm_runtime_get_noresume(). That function requires the callerto already hold an outer runtime PM reference and warns if noneis held: [46.891177] xe 0000:03:00.0: [drm] Missing outer runtime PM protection [46.891178] WARNING: drivers/gpu/drm/xe/xe_pm.c:885 at xe_pm_runtime_get_noresume+0x8b/0xc0Fix this by protecting xe_gt_reset() with the scope-basedguard(xe_pm_runtime)(xe), which is the preferred form whenthe reference lifetime matches a single scope.v2:- Use scope-based guard(xe_pm_runtime)(xe) (Shuicheng)- Update commit message accordingly(cherry picked from commit 7937ea733f79b3f25e802a0c8360bf7423856f36)
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfs: scrub: unlock dquot before early return in quota scrubxchk_quota_item can return early after calling xchk_fblock_process_error.When that helper returns false, the function returned immediately withoutdropping dq->q_qlock, which can leave the dquot lock held and risk lockleaks or deadlocks in later quota operations.Fix this by unlocking dq->q_qlock before the early return.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:spi: spi-dw-dma: fix print error log when wait finish transactionIf an error occurs, the device may not have a current message. In thiscase, the system will crash.In this case, it's better to use dev from the struct ctlr (struct spi_controller*).
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits maskCommit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask sothat whenever something else modifies CR4, that bit remains set. Whichin itself is a perfectly fine idea.However, there's an issue when during boot FRED is initialized: first onthe BSP and later on the APs. Thus, there's a window in time whenexceptions cannot be handled.This becomes particularly nasty when running as SEV-{ES,SNP} or TDXguests which, when they manage to trigger exceptions during that shortwindow described above, triple fault due to FRED MSRs not being set upyet.See Link tag below for a much more detailed explanation of thesituation.So, as a result, the commit in that Link URL tried to address thisshortcoming by temporarily disabling CR4 pinning when an AP is notonline yet.However, that is a problem in itself because in this case, an attack onthe kernel needs to only modify the online bit - a single bit in RWmemory - and then disable CR4 pinning and then disable SM*P, leading tomore and worse things to happen to the system.So, instead, remove the FRED bit from the CR4 pinning mask, thusobviating the need to temporarily disable CR4 pinning.If someone manages to disable FRED when poking at CR4, thenidt_invalidate() would make sure the system would crash'n'burn on thefirst exception triggered, which is a much better outcome security-wise.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: dsi: Store driver data before invoking mipi_dsi_host_registerThe call to mipi_dsi_host_register triggers a callback to mtk_dsi_bind,which uses dev_get_drvdata to retrieve the mtk_dsi struct, so thisstructure needs to be stored inside the driver data before invoking it.As drvdata is currently uninitialized it leads to a crash whenregistering the DSI DRM encoder right after acquiringthe mode_config.idr_mutex, blocking all subsequent DRM operations.Fixes the following crash during mediatek-drm probe (tested on XiaomiSmart Clock x04g):Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[...]Modules linked in: mediatek_drm(+) drm_display_helper cec drm_client_lib drm_dma_helper drm_kms_helper panel_simple[...]Call trace: drm_mode_object_add+0x58/0x98 (P) __drm_encoder_init+0x48/0x140 drm_encoder_init+0x6c/0xa0 drm_simple_encoder_init+0x20/0x34 [drm_kms_helper] mtk_dsi_bind+0x34/0x13c [mediatek_drm] component_bind_all+0x120/0x280 mtk_drm_bind+0x284/0x67c [mediatek_drm] try_to_bring_up_aggregate_device+0x23c/0x320 __component_add+0xa4/0x198 component_add+0x14/0x20 mtk_dsi_host_attach+0x78/0x100 [mediatek_drm] mipi_dsi_attach+0x2c/0x50 panel_simple_dsi_probe+0x4c/0x9c [panel_simple] mipi_dsi_drv_probe+0x1c/0x28 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __device_attach_driver+0xbc/0x17c bus_for_each_drv+0x88/0xf0 __device_attach+0x9c/0x1cc device_initial_probe+0x54/0x60 bus_probe_device+0x34/0xa0 device_add+0x5b0/0x800 mipi_dsi_device_register_full+0xdc/0x16c mipi_dsi_host_register+0xc4/0x17c mtk_dsi_probe+0x10c/0x260 [mediatek_drm] platform_probe+0x5c/0xa4 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x24/0x30 bus_add_driver+0x11c/0x240 driver_register+0x68/0x130 __platform_register_drivers+0x64/0x160 mtk_drm_init+0x24/0x1000 [mediatek_drm] do_one_initcall+0x60/0x1d0 do_init_module+0x54/0x240 load_module+0x1838/0x1dc0 init_module_from_file+0xd8/0xf0 __arm64_sys_finit_module+0x1b4/0x428 invoke_syscall.constprop.0+0x48/0xc8 do_el0_svc+0x3c/0xb8 el0_svc+0x34/0xe8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19cCode: 52800022 941004ab 2a0003f3 37f80040 (29005a80)
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix deadlock during netdev reset with active connectionsResolve deadlock that occurs when user executes netdev reset while RDMAapplications (e.g., rping) are active. The netdev reset causes icedriver to remove irdma auxiliary driver, triggering device_delete andsubsequent client removal. During client removal, uverbs_client waitsfor QP reference count to reach zero while cma_client holds the finalreference, creating circular dependency and indefinite wait in iWARPmode. Skip QP reference count wait during device reset to preventdeadlock.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Add missing secure storage access fixups for donated memoryThere are special cases where secure storage access exceptions happenin a kernel context for pages that don't have the PG_arch_1 bitset. That bit is set for non-exported guest secure storage (memory)but is absent on storage donated to the Ultravisor since the kernelisn't allowed to export donated pages.Prior to this patch we would try to export the page by callingarch_make_folio_accessible() which would instantly return since thearch bit is absent signifying that the page was already exported andno further action is necessary. This leads to secure storage accessexception loops which can never be resolved.With this patch we unconditionally try to export and if that fails wefixup.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/userfaultfd: fix hugetlb fault mutex hash calculationIn mfill_atomic_hugetlb(), linear_page_index() is used to calculate thepage index for hugetlb_fault_mutex_hash(). However, linear_page_index()returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()expects the index in huge page units. This mismatch means that differentaddresses within the same huge page can produce different hash values,leading to the use of different mutexes for the same huge page. This cancause races between faulting threads, which can corrupt the reservationmap and trigger the BUG_ON in resv_map_release().Fix this by introducing hugetlb_linear_page_index(), which returns thepage index in huge page granularity, and using it in place oflinear_page_index().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exitwg_netns_pre_exit() manually acquires rtnl_lock() inside thepernet .pre_exit callback. This causes a hung task when anotherthread holds rtnl_mutex - the cleanup_net workqueue (or thesetup_net failure rollback path) blocks indefinitely inwg_netns_pre_exit() waiting to acquire the lock.Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:Add ->exit_rtnl() hook to struct pernet_operations."), where theframework already holds RTNL and batches all callbacks under asingle rtnl_lock()/rtnl_unlock() pair, eliminating the contentionwindow.The rcu_assign_pointer(wg->creating_net, NULL) is safe to movefrom .pre_exit to .exit_rtnl (which runs after synchronize_rcu())because all RCU readers of creating_net either use maybe_get_net()- which returns NULL for a dying namespace with zero refcount - oraccess net->user_ns which remains valid throughout the entireops_undo_list sequence.[ Jason: added __net_exit and __read_mostly annotations that were missing. ]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardownepf_ntb_epc_destroy() duplicates the teardown that the caller issupposed to perform later. This leads to an oops when .allow_link failsor when .drop_link is performed. The following is an example oops of theformer case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...]Remove the helper, and drop pci_epc_put(). EPC device refcounting istied to the configfs EPC group lifetime, and pci_epc_put() in the.drop_link path is sufficient.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle invalid dinode in ocfs2_group_extend[BUG]kernel BUG at fs/ocfs2/resize.c:308!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1feCall Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ...[CAUSE]ocfs2_group_extend() assumes that the global bitmap inode blockreturned from ocfs2_inode_lock() has already been validated andBUG_ONs when the signature is not a dinode. That assumption is toostrong for crafted filesystems because the JBD2-managed buffer pathcan bypass structural validation and return an invalid dinode to theresize ioctl.[FIX]Validate the dinode explicitly in ocfs2_group_extend(). If the globalbitmap buffer does not contain a valid dinode, report filesystemcorruption with ocfs2_error() and fail the resize operation instead ofcrashing the kernel.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFOMuch like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divideby zero error"), we also need to prevent that same crash from happeningin the udlfb driver as it uses pixclock directly when dividing, whichwill crash.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: clamp report_size in s32ton() to avoid undefined shifts32ton() shifts by n-1 where n is the field's report_size, a value thatcomes directly from a HID device. The HID parser bounds report_sizeonly to <= 256, so a broken HID device can supply a report descriptorwith a wide field that triggers shift exponents up to 256 on a 32-bittype when an output report is built via hid_output_field() orhid_set_field().Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds inhid_report_raw_event") added the same n > 32 clamp to the functionsnto32(), but s32ton() was never given the same fix as I guess syzbothadn't figured out how to fuzz a device the same way.Fix this up by just clamping the max value of n, just like snto32()does.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: proc: size address buffers for %pISpc outputThe AF_RXRPC procfs helpers format local and remote socket addresses intofixed 50-byte stack buffers with "%pISpc".That is too small for the longest current-tree IPv6-with-port form theformatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses adotted-quad tail not only for v4mapped addresses, but also for ISATAPaddresses via ipv6_addr_is_isatap().As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535is possible with the current formatter. That is 50 visible characters, so51 bytes including the trailing NUL, which does not fit in the existingchar[50] buffers used by net/rxrpc/proc.c.Size the buffers from the formatter's maximum textual form and switch thecall sites to scnprintf().Changes since v1:- correct the changelog to cite the actual maximum current-tree case explicitly- frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: reject undecryptable rxkad response ticketsrxkad_decrypt_ticket() decrypts the RXKAD response ticket and thenparses the buffer as plaintext without checking whethercrypto_skcipher_decrypt() succeeded.A malformed RESPONSE can therefore use a non-block-aligned ticketlength, make the decrypt operation fail, and still drive the ticketparser with attacker-controlled bytes.Check the decrypt result and abort the connection with RXKADBADTICKETwhen ticket decryption fails.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix key reference count leak from call->keyWhen creating a client call in rxrpc_alloc_client_call(), the code obtainsa reference to the key. This is never cleaned up and gets leaked when thecall is destroyed.Fix this by freeing call->key in rxrpc_destroy_call().Before the patch, it shows the key reference counter elevated:$ cat /proc/keys | grep afs@543211bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka$After the patch, the invalidated key is removed when the code exits:$ cat /proc/keys | grep afs@54321$
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix call removal to use RCU safe deletionFix rxrpc call removal from the rxnet->calls list to use list_del_rcu()rather than list_del_init() to prevent stuffing up reading/proc/net/rxrpc/calls from potentially getting into an infinite loop.This, however, means that list_empty() no longer works on an entry that'sbeen deleted from the list, making it harder to detect prior deletion. Fixthis by:Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls thatare unexpectedly still on the list. Limiting the number of steps meansthere's no need to call cond_resched() or to remove calls from the listhere, thereby eliminating the need for rxrpc_put_call() to check for that.rxrpc_put_call() can then be fixed to unconditionally delete the call fromthe list as it is the only place that the deletion occurs.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()page_pool_create() can return an ERR_PTR on failure. The return valueis used unconditionally in the loop that follows, passing the errorpointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),which dereferences it, causing a kernel oops.Add an IS_ERR check after page_pool_create() to return early on failure.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handlingSwitch from using the completion's raw spinlock to a local lock in theidpf_vc_xn struct. The conversion is safe because complete/_all() arecalled outside the lock and there is no reason to share the completionlock in the current logic. This avoids invalid wait context reported bythe kernel due to the async handler taking BH spinlock:[ 805.726977] =============================[ 805.726991] [ BUG: Invalid wait context ][ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE[ 805.727026] -----------------------------[ 805.727038] kworker/u261:0/572 is trying to lock:[ 805.727051] ff190da6a8dbb6a0 (&vport_config->mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727099] other info that might help us debug this:[ 805.727111] context-{5:5}[ 805.727119] 3 locks held by kworker/u261:0/572:[ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730[ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter->mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730[ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf][ 805.727218] stack backtrace:...[ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf][ 805.727247] Call Trace:[ 805.727249] [ 805.727251] dump_stack_lvl+0x77/0xb0[ 805.727259] __lock_acquire+0xb3b/0x2290[ 805.727268] ? __irq_work_queue_local+0x59/0x130[ 805.727275] lock_acquire+0xc6/0x2f0[ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727284] ? _printk+0x5b/0x80[ 805.727290] _raw_spin_lock_bh+0x38/0x50[ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf][ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf][ 805.727317] process_one_work+0x226/0x730[ 805.727322] worker_thread+0x19e/0x340[ 805.727325] ? __pfx_worker_thread+0x10/0x10[ 805.727328] kthread+0xf4/0x130[ 805.727333] ? __pfx_kthread+0x10/0x10[ 805.727336] ret_from_fork+0x32c/0x410[ 805.727345] ? __pfx_kthread+0x10/0x10[ 805.727347] ret_from_fork_asm+0x1a/0x30[ 805.727354]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabledKeep the NOC_HDCP clock always enabled to fix the potential hangcaused by the NoC ADB400 port power down handshake.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: clear trailing padding in build_polexpire()build_expire() clears the trailing padding bytes of structxfrm_user_expire after setting the hard field via memset_after(),but the analogous function build_polexpire() does not do this forstruct xfrm_user_polexpire.The padding bytes after the __u8 hard field are leftuninitialized from the heap allocation, and are then sent touserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,leaking kernel heap memory contents.Add the missing memset_after() call, matching build_expire().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref()After commit 1618aa3c2e01 ("btrfs: simplify return variables inlookup_extent_data_ref()"), the err and ret variables were merged intoa single ret variable. However, when btrfs_next_leaf() returns 0(success), ret is overwritten from -ENOENT to 0. If the first key inthe next leaf does not match (different objectid or type), the functionreturns 0 instead of -ENOENT, making the caller believe the lookupsucceeded when it did not. This can lead to operations on the wrongextent tree item, potentially causing extent tree corruption.Fix this by returning -ENOENT directly when the key does not match,instead of relying on the ret variable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: prevent unlimited numbers of rfkill events from being createdUserspace can create an unlimited number of rfkill events if the systemis so configured, while not consuming them from the rfkill filedescriptor, causing a potential out of memory situation. Prevent thisfrom bounding the number of pending rfkill events at a "large" number(i.e. 1000) to prevent abuses like this.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS.rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[].Validate addrnr during rule installation so malformed rules are rejectedbefore the match logic can use an out-of-range value.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix missing validation of ticket length in non-XDR key preparsingIn rxrpc_preparse(), there are two paths for parsing key payloads: theXDR path (for large payloads) and the non-XDR path (for payloads <= 28bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctlyvalidates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDRpath fails to do so.This allows an unprivileged user to provide a very large ticket length.When this key is later read via rxrpc_read(), the totaltoken size (toksize) calculation results in a value that exceedsAFSTOKEN_LENGTH_MAX, triggering a WARN_ON().[ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc]Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse()to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX,bringing it into parity with the XDR parsing logic.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io()In f2fs_compress_write_end_io(), dec_page_count(sbi, type) can bringthe F2FS_WB_CP_DATA counter to zero, unblockingf2fs_wait_on_all_pages() in f2fs_put_super() on a concurrent unmountCPU. The unmount path then proceeds to callf2fs_destroy_page_array_cache(sbi), which destroyssbi->page_array_slab via kmem_cache_destroy(), and eventuallykfree(sbi). Meanwhile, the bio completion callback is still executing:when it reaches page_array_free(sbi, ...), it dereferencessbi->page_array_slab - a destroyed slab cache - to callkmem_cache_free(), causing a use-after-free.This is the same class of bug as CVE-2026-23234 (which fixed theequivalent race in f2fs_write_end_io() in data.c), but in thecompressed writeback completion path that was not covered by that fix.Fix this by moving dec_page_count() to after page_array_free(), sothat all sbi accesses complete before the counter decrement that canunblock unmount. For non-last folios (where atomic_dec_return oncic->pending_pages is nonzero), dec_page_count is called immediatelybefore returning - page_array_free is not reached on this path, sothere is no post-decrement sbi access. For the last folio,page_array_free runs while the F2FS_WB_CP_DATA counter is stillnonzero (this folio has not yet decremented it), keeping sbi alive,and dec_page_count runs as the final operation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:writeback: Fix use after free in inode_switch_wbs_work_fn()inode_switch_wbs_work_fn() has a loop like: wb_get(new_wb); while (1) { list = llist_del_all(&new_wb->switch_wbs_ctxs); /* Nothing to do? */ if (!list) break; ... process the items ... }Now adding of items to the list looks like:wb_queue_isw() if (llist_add(&isw->list, &wb->switch_wbs_ctxs)) queue_work(isw_wq, &wb->switch_work);Because inode_switch_wbs_work_fn() loops when processing isw items, itcan happen that wb->switch_work is pending while wb->switch_wbs_ctxs isempty. This is a problem because in that case wb can get freed (no iswitems -> no wb reference) while the work is still pending causinguse-after-free issues.We cannot just fix this by cancelling work when freeing wb because thatcould still trigger problematic 0 -> 1 transitions on wb refcount due towb_get() in inode_switch_wbs_work_fn(). It could be all handled withmore careful code but that seems unnecessarily complex so let's avoidthat until it is proven that the looping actually brings practicalbenefit. Just remove the loop from inode_switch_wbs_work_fn() instead.That way when wb_queue_isw() queues work, we are guaranteed we haveadded the first item to wb->switch_wbs_ctxs and nobody is going toremove it (and drop the wb reference it holds) until the queued workruns.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: use check_add_overflow() to prevent u16 DACL size overflowset_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizesin u16 variables. When a file has many POSIX ACL entries, theaccumulated size can wrap past 65535, causing the pointer arithmetic(char *)pndace + *size to land within already-written ACEs. Subsequentwrites then overwrite earlier entries, and pndacl->size gets atruncated value.Use check_add_overflow() at each accumulation point to detect thewrap before it corrupts the buffer, consistent with existingcheck_mul_overflow() usage elsewhere in smbacl.c.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xen/privcmd: fix double free via VMA splittingprivcmd_vm_ops defines .close (privcmd_close), but neither .may_splitnor .open. When userspace does a partial munmap() on a privcmd mapping,the kernel splits the VMA via __split_vma(). Since may_split is NULL,the split is allowed. vm_area_dup() copies vm_private_data (a pagesarray allocated in alloc_empty_pages()) into the new VMA without anyfixup, because there is no .open callback.Both VMAs now point to the same pages array. When the unmapped portionis closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages)The surviving VMA still holds the dangling pointer. When it is laterdestroyed, the same sequence runs again, which leads to a double free.Fix this issue by adding a .may_split callback denying the VMA split.This is XSA-487 / CVE-2026-31787
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject immediate NF_QUEUE verdictnft_queue is always used from userspace nftables to deliver the NF_QUEUEverdict. Immediately emitting an NF_QUEUE verdict is never used by theuserspace nft tools, so reject immediate NF_QUEUE verdicts.The arp family does not provide queue support, but such an immediateverdict is still reachable. Globally reject NF_QUEUE immediate verdictsto address this issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absentctnetlink_alloc_expect() allocates expectations from a non-zeroingslab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is notpresent in the netlink message, saved_addr and saved_proto arenever initialized. Stale data from a previous slab occupant canthen be dumped to userspace by ctnetlink_exp_dump_expect(), whichchecks these fields to decide whether to emit CTA_EXPECT_NAT.The safe sibling nf_ct_expect_init(), used by the packet path,explicitly zeroes these fields.Zero saved_addr, saved_proto and dir in the else branch, guardedby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist whenNAT is enabled.Confirmed by priming the expect slab with NAT-bearing expectations,freeing them, creating a new expectation without CTA_EXPECT_NAT,and observing that the ctnetlink dump emits a spuriousCTA_EXPECT_NAT containing stale data from the prior allocation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: ensure names are nul-terminatedReject names that lack a \0 character before feeding themto functions that expect c-strings.Fixes tag is the most recent commit that needs this change.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libpolkit-agent-1-0 > 0-0 (version in image is 123-160000.2.2).
Description: A flaw was found in firewalld. A local unprivileged user can exploit this vulnerability by mis-authorizing two runtime D-Bus (Desktop Bus) setters, setZoneSettings2 and setPolicySettings. This mis-authorization allows the user to modify the runtime firewall state without proper authentication, leading to unauthorized changes in network security configurations.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
firewalld > 0-0 (version in image is 2.1.2-160000.2.2).
Description: A flaw was found in the System Security Services Daemon (SSSD). The pam_passkey_child_read_data() function within the PAM passkey responder fails to properly handle raw bytes received from a pipe. Because the data is treated as a NUL-terminated C string without explicit termination, it results in an out-of-bounds read when processed by functions like snprintf(). A local attacker could potentially trigger this vulnerability by initiating a crafted passkey authentication request, causing the SSSD PAM responder to crash, resulting in a local Denial of Service (DoS).
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libsss_idmap0 > 0-0 (version in image is 2.9.5-160000.3.1).
Description: A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node's Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libefivar1 > 0-0 (version in image is 38-160000.2.2).
Description: Rack is a modular Ruby web server interface. Prior to versions 2.2.22, 3.1.20, and 3.2.5, `Rack::Directory` generates an HTML directory index where each file entry is rendered as a clickable link. If a file exists on disk whose basename starts with the `javascript:` scheme (e.g. `javascript:alert(1)`), the generated index contains an anchor whose `href` is exactly `javascript:alert(1)`. Clicking the entry executes JavaScript in the browser (demonstrated with `alert(1)`). Versions 2.2.22, 3.1.20, and 3.2.5 fix the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313-urllib3 < 2.5.0-160000.5.1 (version in image is 2.5.0-160000.4.1).
Description: pytest through 9.0.2 on UNIX relies on directories with the /tmp/pytest-of-{user} name pattern, which allows local users to cause a denial of service or possibly gain privileges.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313-pytest > 0-0 (version in image is 8.3.5-160000.2.2).
Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix __perf_event_overflow() vs perf_remove_from_context() raceMake sure that __perf_event_overflow() runs with IRQs disabled for allpossible callchains. Specifically the software events can end up runningit with only preemption disabled.This opens up a race vs perf_event_exit_event() and friends that will goand free various things the overflow path expects to be present, likethe BPF program.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:atm: lec: fix null-ptr-deref in lec_arp_clear_vccssyzkaller reported a null-ptr-deref in lec_arp_clear_vccs().This issue can be easily reproduced using the syzkaller reproducer.In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared bymultiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc).When the underlying VCC is closed, lec_vcc_close() iterates over allARP entries and calls lec_arp_clear_vccs() for each matched entry.For example, when lec_vcc_close() iterates through the hlists inpriv->lec_arp_empty_ones or other ARP tables:1. In the first iteration, for the first matched ARP entry sharing the VCC,lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back)and sets vcc->user_back to NULL.2. In the second iteration, for the next matched ARP entry sharing the sameVCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv fromvcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference itvia `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash.Fix this by adding a null check for vpriv before dereferencingit. If vpriv is already NULL, it means the VCC has been clearedby a previous call, so we can safely skip the cleanup and justclear the entry's vcc/recv_vcc pointers.The entire cleanup block (including vcc_release_async()) is placed insidethe vpriv guard because a NULL vpriv indicates the VCC has already beenfully released by a prior iteration - repeating the teardown wouldredundantly set flags and trigger callbacks on an already-closing socket.The Fixes tag points to the initial commit because the entry->vcc path hasbeen vulnerable since the original code. The entry->recv_vcc path was lateradded by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back")with the same pattern, and both paths are fixed here.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libfreetype6 > 0-0 (version in image is 2.13.3-160000.3.1).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:spi: use generic driver_override infrastructureWhen a driver is probed through __driver_attach(), the bus' match()callback is called without the device lock held, thus accessing thedriver_override field without a lock, which can cause a UAF.Fix this by using the driver-core driver_override infrastructure takingcare of proper locking internally.Note that calling match() from __driver_attach() without the device lockheld is intentional. [1]Also note that we do not enable the driver_override feature of structbus_type, as SPI - in contrast to most other buses - passes "" tosysfs_emit() when the driver_override pointer is NULL. Thus, printing"\n" instead of "(null)\n".
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timerand id_addr_timer while holding conn->lock. However, the work functionsl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquireconn->lock, creating a potential AB-BA deadlock if the work is alreadyexecuting when l2cap_conn_del() takes the lock.Move the work cancellations before acquiring conn->lock and usedisable_delayed_work_sync() to additionally prevent the works frombeing rearmed after cancellation, consistent with the pattern used inhci_conn_del().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Vim is an open source, command line text editor. From 9.1.0011 to before 9.2.0137, Vim's NFA regex compiler, when encountering a collection containing a combining character as the endpoint of a character range (e.g. [0-0\u05bb]), incorrectly emits the composing bytes of that character as separate NFA states. This corrupts the NFA postfix stack, resulting in NFA_START_COLL having a NULL out1 pointer. When nfa_max_width() subsequently traverses the compiled NFA to estimate match width for the look-behind assertion, it dereferences state->out1->out without a NULL check, causing a segmentation fault. This vulnerability is fixed in 9.2.0137.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.2 and newer fail to enforce the caller-supplied buffer length, and can result in an out-of-bounds write when printing TSIG records.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glibc > 0-0 (version in image is 2.40-160000.4.1).
Description: The deprecated functions ns_printrrf, ns_printrr and fp_nquery in the GNU C Library version 2.2 and newer fail to validate the RDATA content against the RDATA length in a DNS response when processing LOC, CERT, TKEY or TSIG records, which may allow an attacker to craft a DNS response, causing a target application to crash or read uninitialized memory.These functions are for application debugging only and hence not in the path of code executed by the DNS resolver. Further, they have been deprecated since version 2.34 and should not be used by any new applications. Applications should consider porting away from these interfaces since they may be removed in future versions.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glibc > 0-0 (version in image is 2.40-160000.4.1).
Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libpng16-16 < 1.6.44-160000.7.1 (version in image is 1.6.44-160000.6.1).
Description: A malicious SCP server can send unexpected paths that could make theclient application override local files outside of working directory.This could be misused to create malicious executable or configurationfiles and make the user execute them under specific consequences.This is the same issue as in OpenSSH, tracked as CVE-2019-6111.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
glib2-tools > 0-0 (version in image is 2.84.4-160000.2.1).
Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: avoid OGM aggregation when skb tailroom is insufficientWhen OGM aggregation state is toggled at runtime, an existing forwardedpacket may have been allocated with only packet_len bytes, while a laterpacket can still be selected for aggregation. Appending in this case canhit skb_put overflow conditions.Reject aggregation when the target skb tailroom cannot accommodate the newpacket. The caller then falls back to creating a new forward packetinstead of appending.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix locking for runpm vs reclaimFor cases where icc_bw_set() can be called in callbaths that coulddeadlock against shrinker/reclaim, such as runpm resume, we need todecouple the icc locking. Introduce a new icc_bw_lock for cases wherewe need to serialize bw aggregation and update to decouple that frompaths that require memory allocation such as node/link creation/destruction.Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_---truncated---
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Use raw_spinlock_t in ringbufThe function __bpf_ringbuf_reserve is invoked from a tracepoint, whichdisables preemption. Using spinlock_t in this context can lead to a"sleep in atomic" warning in the RT variant. This issue is illustratedin the example below:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progspreempt_count: 1, expected: 0RCU nest depth: 1, expected: 1INFO: lockdep is turned off.Preemption disabled at:[] migrate_enable+0xc0/0x39cCPU: 7 PID: 556208 Comm: test_progs Tainted: GHardware name: Qualcomm SA8775P Ride (DT)Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180Switch the spinlock to raw_spinlock_t to avoid this error.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()build_skb() returns NULL in case of a memory allocation failure so handleit inside __octep_oq_process_rx() to avoid NULL pointer dereference.__octep_oq_process_rx() is called during NAPI polling by the driver. Ifskb allocation fails, keep on pulling packets out of the Rx DMA queue: weshouldn't break the polling immediately and thus falsely indicate to theoctep_napi_poll() that the Rx pressure is going down. As there is noassociated skb in this case, don't process the packets and don't push themup the network stack - they are skipped.Helper function is implemented to unmmap/flush all the fragment buffersused by the dropped packet. 'alloc_failures' counter is incremented tomark the skb allocation error in driver statistics.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make sure internal and UAPI bpf_redirect flags don't overlapThe bpf_redirect_info is shared between the SKB and XDP redirect paths,and the two paths use the same numeric flag values in the ri->flagsfield (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means thatif skb bpf_redirect_neigh() is used with a non-NULL params argument and,subsequently, an XDP redirect is performed using the samebpf_redirect_info struct, the XDP path will get confused and end upcrashing, which syzbot managed to trigger.With the stack-allocated bpf_redirect_info, the structure is no longershared between the SKB and XDP paths, so the crash doesn't happenanymore. However, different code paths using identically-numbered flagvalues in the same struct field still seems like a bit of a mess, sothis patch cleans that up by moving the flag definitions together andredefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlapwith the flags used for XDP. It also adds a BUILD_BUG_ON() check to makesure the overlap is not re-introduced by mistake.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:arm64: dts: qcom: x1e80100: Add GPU coolingUnlike the CPU, the GPU does not throttle its speed automatically when itreaches high temperatures. With certain high GPU loads it is possible toreach the critical hardware shutdown temperature of 120?C, endangering thehardware and making it impossible to run certain applications.Set up GPU cooling similar to the ACPI tables, by throttling the GPU speedwhen reaching 95?C and polling every 200ms.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: remove mutex_lock check in hfsplus_free_extentsSyzbot reported an issue in hfsplus filesystem:------------[ cut here ]------------WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0Call Trace:hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56cont_expand_zero fs/buffer.c:2383 [inline]cont_write_begin+0x2cf/0x860 fs/buffer.c:2446hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263notify_change+0xe38/0x10f0 fs/attr.c:420do_truncate+0x1fb/0x2e0 fs/open.c:65do_sys_ftruncate+0x2eb/0x380 fs/open.c:193do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdTo avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlockon file truncation") unlock extree before hfsplus_free_extents(),and add check wheather extree is locked in hfsplus_free_extents().However, when operations such as hfsplus_file_release,hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executedconcurrently in different files, it is very likely to trigger theWARN_ON, which will lead syzbot and xfstest to consider it as anabnormality.The comment above this warning also describes one of the easytriggering situations, which can easily trigger and causexfstest&syzbot to report errors.[task A] [task B]->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!Several threads could try to lock the shared extents tree.And warning can be triggered in one thread when another threadhas locked the tree. This is the wrong behavior of the code andwe need to remove the warning.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:procfs: avoid fetching build ID while holding VMA lockFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lockor per-VMA lock, whichever was used to lock VMA under question, to avoiddeadlock reported by syzbot: -> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xed/0x170 _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}: __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0 __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock); lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8); *** DEADLOCK ***This seems to be exacerbated (as we haven't seen these syzbot reportsbefore that) by the recent: 777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")To make this safe, we need to grab file refcount while VMA is still locked, butother than that everything is pretty straightforward. Internal build_id_parse()API assumes VMA is passed, but it only needs the underlying file reference, sojust add another variant build_id_parse_file() that expects file passeddirectly.[akpm@linux-foundation.org: fix up kerneldoc]
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: add proper RCU protection to /proc/net/ptypeYin Fengwei reported an RCU stall in ptype_seq_show() and provideda patch.Real issue is that ptype_seq_next() and ptype_seq_show() violateRCU rules.ptype_seq_show() runs under rcu_read_lock(), and reads pt->devto get device name without any barrier.At the same time, concurrent writers can remove a packet_type structure(which is correctly freed after an RCU grace period) and clear pt->devwithout an RCU grace period.Define ptype_iter_state to carry a dev pointer along seq_net_private:struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch};We need to record the device pointer in ptype_get_idx() andptype_seq_next() so that ptype_seq_show() is safe againstconcurrent pt->dev changes.We also need to add full RCU protection in ptype_seq_next().(Missing READ_ONCE() when reading list.next values)Many thanks to Dong Chenchen for providing a repro.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()l3mdev_master_dev_rcu() can return NULL when the slave device is beingun-slaved from a VRF. All other callers deal with this, but we lostthe fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu()with commit 4832c30d5458 ("net: ipv6: put host and anycast routes ondevice with address"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437)I was tempted to rework the un-slaving code to clear the flag firstand insert synchronize_rcu() before we remove the upper. But looks likethe explicit fallback to loopback_dev is an established pattern.And I guess avoiding the synchronize_rcu() is nice, too.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boostingRunning stress-ng --schedpolicy 0 on an RT kernel on a big machinemight lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ...The problem is that when a SCHED_DEADLINE task (lock holder) ischanged to a lower priority class via sched_setscheduler(), it mayfail to properly inherit the parameters of potential DEADLINE donorsif it didn't already inherit them in the past (shorter deadline thandonor's at that time). This might lead to bandwidth accountingcorruption, as enqueue_task_dl() won't recognize the lock holder asboosted.The scenario occurs when:1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline)2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happenFix the issue by introducing __setscheduler_dl_pi(), which detects whena DEADLINE (proper or boosted) task gets setscheduled to a lowerpriority class. In case, the function makes the task inherit DEADLINEparameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag toensure proper bandwidth accounting during the next enqueue operation.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nf_tables: nft_dynset: fix possible stateful expression memleak in error pathIf cloning the second stateful expression in the element via GFP_ATOMICfails, then the first stateful expression remains in place without beingreleased. unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:tls: Purge async_hold in tls_decrypt_async_wait()The async_hold queue pins encrypted input skbs whilethe AEAD engine references their scatterlist data. Oncetls_decrypt_async_wait() returns, every AEAD operationhas completed and the engine no longer references thoseskbs, so they can be freed unconditionally.A subsequent patch adds batch async decryption totls_sw_read_sock(), introducing a new call site thatmust drain pending AEAD operations and release heldskbs. Move __skb_queue_purge(&ctx->async_hold) intotls_decrypt_async_wait() so the purge is centralizedand every caller -- recvmsg's drain path, the -EBUSYfallback in tls_do_decryption(), and the new read_sockbatch path -- releases held skbs on synchronizationwithout each site managing the purge independently.This fixes a leak when tls_strp_msg_hold() fails part-way through,after having added some cloned skbs to the async_holdqueue. tls_decrypt_sg() will then call tls_decrypt_async_wait() toprocess all pending decrypts, and drop back to synchronous mode, buttls_sw_recvmsg() only flushes the async_hold queue when one record hasbeen processed in "fully-async" mode, which may not be the case here.[pabeni@redhat.com: added leak comment]
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free in update_super_work when racing with umountCommit b98535d09179 ("ext4: fix bug_on in start_this_handle during umountfilesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_workto prevent new error work from being queued via /proc/fs/ext4/xx/mb_groupsreads during unmount. However, this introduced a use-after-free becauseupdate_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() whichaccesses the kobject's kernfs_node after it has been freed by kobject_del()in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work)Instead of reordering the teardown sequence, fix this by makingext4_notify_error_sysfs() detect that sysfs has already been torn downby checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() callin that case. A dedicated mutex (s_error_notify_mutex) serializesext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()to prevent TOCTOU races where the kobject could be deleted between thestate_in_sysfs check and the sysfs_notify() call.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix drm_edid leak in amdgpu_dm[WHAT]When a sink is connected, aconnector->drm_edid was overwritten withoutfreeing the previous allocation, causing a memory leak on resume.[HOW]Free the previous drm_edid before updating it.(cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix potential deadlock in cpu hotplug with osnoiseThe following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK]Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/syscalls: Add spectre boundary for syscall dispatch tableThe s390 syscall number is directly controlled by userspace, but doesnot have an array_index_nospec() boundary to prevent access past thesyscall function pointer tables.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:esp: fix skb leak with espintcp and async cryptoWhen the TX queue for espintcp is full, esp_output_tail_tcp willreturn an error and not free the skb, because with synchronous crypto,the common xfrm output code will drop the packet for us.With async crypto (esp_output_done), we need to drop the skb whenesp_output_tail_tcp returns an error.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: bcm: bcm2835-power: Increase ASB control timeoutThe bcm2835_asb_control() function uses a tight polling loop to waitfor the ASB bridge to acknowledge a request. During intensive workloads,this handshake intermittently fails for V3D's master ASB on BCM2711,resulting in "Failed to disable ASB master for v3d" errors duringruntime PM suspend. As a consequence, the failed power-off leaves V3D ina broken state, leading to bus faults or system hangs on later accesses.As the timeout is insufficient in some scenarios, increase the pollingtimeout from 1us to 5us, which is still negligible in the context of apower domain transition. Also, replace the open-coded ktime_get_ns()/cpu_relax() polling loop with readl_poll_timeout_atomic().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: amdisp: Fix resume-probe race condition issueIdentified resume-probe race condition in kernel v7.0 with the commit38fa29b01a6a ("i2c: designware: Combine the init functions"),but thisissue existed from the beginning though not detected.The amdisp i2c device requires ISP to be in power-on state for probeto succeed. To meet this requirement, this device is added to genpdto control ISP power using runtime PM. The pm_runtime_get_sync() calledbefore i2c_dw_probe() triggers PM resume, which powers on ISP and alsoinvokes the amdisp i2c runtime resume before the probe completes resultingin this race condition and a NULL dereferencing issue in v7.0Fix this race condition by using the genpd APIs directly during probe: - Call dev_pm_genpd_resume() to Power ON ISP before probe - Call dev_pm_genpd_suspend() to Power OFF ISP after probe - Set the device to suspended state with pm_runtime_set_suspended() - Enable runtime PM only after the device is fully initialized
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix reference count leak in rxrpc_server_keyring()This patch fixes a reference count leak in rxrpc_server_keyring()by checking if rx->securities is already set.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()When dma_map_single() fails in tse_start_xmit(), the function returnsNETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells thestack the packet was consumed, the skb is never freed, leaking memoryon every DMA mapping failure.Add dev_kfree_skb_any() before returning to properly free the skb.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: flowlabel: defer exclusive option free until RCU teardown`ip6fl_seq_show()` walks the global flowlabel hash under the seq-fileRCU read-side lock and prints `fl->opt->opt_nflen` when an option blockis present.Exclusive flowlabels currently free `fl->opt` as soon as `fl->users`drops to zero in `fl_release()`. However, the surrounding`struct ip6_flowlabel` remains visible in the global hash table untillater garbage collection removes it and `fl_free_rcu()` finally tears itdown.A concurrent `/proc/net/ip6_flowlabel` reader can therefore race thatearly `kfree()` and dereference freed option state, triggering a crashin `ip6fl_seq_show()`.Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matchesthe lifetime already required for the enclosing flowlabel while readerscan still reach it under RCU.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: validate USB endpointsThe pegasus driver should validate that the device it is probing has theproper number and types of USB endpoints it is expecting before it bindsto it. If a malicious device were to not have the same urbs the driverwill crash later on when it blindly accesses these endpoints.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()A malicious USB device claiming to be a CDC Phonet modem can overflowthe skb_shared_info->frags[] array by sending an unbounded sequence offull-page bulk transfers.Drop the skb and increment the length error when the frag limit isreached. This matches the same fix that commit f0813bcd2d9d ("net:wwan: t7xx: fix potential skb->frags overflow in RX path") did for thet7xx driver.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: read UNIX_DIAG_VFS data under unix_state_lockExact UNIX diag lookups hold a reference to the socket, but not tou->path. Meanwhile, unix_release_sock() clears u->path underunix_state_lock() and drops the path reference after unlocking.Read the inode and device numbers for UNIX_DIAG_VFS while holdingunix_state_lock(), then emit the netlink attribute after dropping thelock.This keeps the VFS data stable while the reply is being built.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: There is a flaw in RPM's signature functionality. OpenPGP subkeys are associated with a primary key via a "binding signature." RPM does not check the binding signature of subkeys prior to importing them. If an attacker is able to add or socially engineer another party to add a malicious subkey to a legitimate public key, RPM could wrongly trust a malicious signature. The greatest impact of this flaw is to data integrity. To exploit this flaw, an attacker must either compromise an RPM repository or convince an administrator to install an untrusted RPM or public key. It is strongly recommended to only use RPMs and public keys from trusted sources.
Packages affected:
librpmbuild10 > 0-0 (version in image is 4.20.1-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Packages affected:
podman > 0-0 (version in image is 5.4.2-160000.4.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:iommu/s390: Make attach succeed when the device was surprise removedWhen a PCI device is removed with surprise hotplug, there may still beattempts to attach the device to the default domain as part of tear downvia (__iommu_release_dma_ownership()), or because the removal happensduring probe (__iommu_probe_device()). In both cases zpci_register_ioat()fails with a cc value indicating that the device handle is invalid. Thisis because the device is no longer part of the instance as far as thehypervisor is concerned.Currently this leads to an error return and s390_iommu_attach_device()fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()because attaching to the default domain must never fail.With the device fenced by the hypervisor no DMAs to or from memory arepossible and the IOMMU translations have no effect. Proceed as if theregistration was successful and let the hotplug event handling clean upthe device.This is similar to how devices in the error state are handled sincecommit 59bbf596791b ("iommu/s390: Make attach succeed even if the deviceis in error state") except that for removal the domain will not beregistered later. This approach was also previously discussed at thelink.Handle both cases, error state and removal, in a helper which checks ifthe error needs to be propagated or ignored. Avoid magic numbercondition codes by using the pre-existing, but never used, defines forPCI load/store condition codes and rename them to reflect that theyapply to all PCI instructions.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: libsodium before ad3004e, in atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libsodium26 < 1.0.21-160000.1.1 (version in image is 1.0.20-160000.3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix recursive locking in __configfs_open_file()In flush_write_buffer, &p->frag_sem is acquired and then the loaded storefunction is called, which, here, is target_core_item_dbroot_store(). Thisfunction called filp_open(), following which these functions were called(in reverse order), according to the call trace: down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_itertarget_core_item_dbroot_store() tries to validate the new file path bytrying to open the file path provided to it; however, in this case, the bugreport shows:db_root: not a directory: /sys/kernel/config/target/dbrootindicating that the same configfs file was tried to be opened, on which itis currently working on. Thus, it is trying to acquire frag_sem semaphoreof the same file of which it already holds the semaphore obtained inflush_write_buffer(), leading to acquiring the semaphore in a nested mannerand a possibility of recursive locking.Fix this by modifying target_core_item_dbroot_store() to use kern_path()instead of filp_open() to avoid opening the file using filesystem-specificfunction __configfs_open_file(), and further modifying it to make this fixcompatible.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthopWhen a standalone IPv6 nexthop object is created with a loopback device(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifiesit as a reject route. This is because nexthop objects have no destinationprefix (fc_dst=::), causing fib6_is_reject() to match any loopbacknexthop. The reject path skips fib_nh_common_init(), leavingnhc_pcpu_rth_output unallocated. If an IPv4 route later references thisnexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output andpanics.Simplify the check in fib6_nh_init() to only match explicit rejectroutes (RTF_REJECT) instead of using fib6_is_reject(). The loopbackpromotion heuristic in fib6_is_reject() is handled separately byip6_route_info_create_nh(). After this change, the three cases behaveas follows:1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change.2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless.3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loadedbond_option_mode_set() already rejects mode changes that would make aloaded XDP program incompatible via bond_xdp_check(). However,bond_option_xmit_hash_policy_set() has no such guard.For 802.3ad and balance-xor modes, bond_xdp_check() returns false whenxmit_hash_policy is vlan+srcmac, because the 802.1q payload is usuallyabsent due to hardware offload. This means a user can:1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmit_hash_policy (e.g. layer2+3).2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.This leaves bond->xdp_prog set but bond_xdp_check() now returning falsefor the same device. When the bond is later destroyed, dev_xdp_uninstall()calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hitsthe bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when anXDP program is loaded on a bond in 802.3ad or balance-xor mode.commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP")introduced bond_xdp_check() which returns false for 802.3ad/balance-xormodes when xmit_hash_policy is vlan+srcmac. The check was wired intobond_xdp_set() to reject XDP attachment with an incompatible policy, butthe symmetric path -- preventing xmit_hash_policy from being changed to anincompatible value after XDP is already loaded -- was left unguarded inbond_option_xmit_hash_policy_set().Note:commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode")later added a similar guard to bond_option_mode_set(), butbond_option_xmit_hash_policy_set() remained unprotected.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:nfnetlink_osf: validate individual option lengths in fingerprintsnfnl_osf_add_callback() validates opt_num bounds and stringNUL-termination but does not check individual option length fields.A zero-length option causes nf_osf_match_one() to enter the optionmatching loop even when foptsize sums to zero, which matches packetswith no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573)Additionally, an MSS option (kind=2) with length < 4 causesout-of-bounds reads when nf_osf_match_one() unconditionally accessesoptp[2] and optp[3] for MSS value extraction. While RFC 9293section 3.2 specifies that the MSS option is always exactly 4bytes (Kind=2, Length=4), the check uses "< 4" rather than"!= 4" because lengths greater than 4 do not cause memorysafety issues -- the buffer is guaranteed to be at leastfoptsize bytes by the ctx->optsize == foptsize check.Reject fingerprints where any option has zero length, or where an MSSoption has length less than 4, at add time rather than trusting thesevalues in the packet matching hot path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()A malicious or compromised VIO server can return a num_written value in thediscover targets MAD response that exceeds max_targets. This value isstored directly in vhost->num_targets without validation, and is then usedas the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], whichis only allocated for max_targets entries. Indices at or beyond max_targetsaccess kernel memory outside the DMA-coherent allocation. Theout-of-bounds data is subsequently embedded in Implicit Logout and PLOGIMADs that are sent back to the VIO server, leaking kernel memory.Fix by clamping num_written to max_targets before storing it.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: use the current queue number for statsThere's a potential mismatch between the memory reserved for statisticsand the amount of memory written.gem_get_sset_count() correctly computes the number of stats based on theactive queues, whereas gem_get_ethtool_stats() indiscriminately copiesdata using the maximum number of queues, and in the case the number ofactive queues is less than MACB_MAX_QUEUES, this results in a OOB writeas observed in the KASAN splat.==================================================================BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb]Write of size 760 at addr ffff80008080b000 by task ethtool/1027CPU: [...]Tainted: [E]=UNSIGNED_MODULEHardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0The buggy address belongs to the physical page:page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff)raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================Fix it by making sure the copied size only considers the active number ofqueues.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: bcmasp: fix double free of WoL irqWe do not need to free wol_irq since it was instantiated withdevm_request_irq(). So devres will free for us.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:af_key: validate families in pfkey_send_migrate()syzbot was able to trigger a crash in skb_put() [1]Issue is that pfkey_send_migrate() does not check old/new families,and that set_ipsecrequest() @family argument was truncated,thus possibly overfilling the skb.Validate families early, do not wait set_ipsecrequest().[1]skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 !Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:module: Fix kernel panic when a symbol st_shndx is out of boundsThe module loader doesn't check for bounds of the ELF section index insimplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { const char *name = info->strtab + sym[i].st_name; switch (sym[i].st_shndx) { case SHN_COMMON: [...] default: /* Divert to percpu allocation if a percpu var. */ if (sym[i].st_shndx == info->index.pcpu) secbase = (unsigned long)mod_percpu(mod); else /** HERE --> **/ secbase = info->sechdrs[sym[i].st_shndx].sh_addr; sym[i].st_value += secbase; break; } }A symbol with an out-of-bounds st_shndx value, for example 0xffff(known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exceptionThis can happen when module ELF is legitimately using SHN_XINDEX orwhen it is corrupted.Add a bounds check in simplify_symbols() to validate that st_shndx iswithin the valid range before using it.This issue was discovered due to a bug in llvm-objcopy, see relevantdiscussion for details [1].[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:seg6: separate dst_cache for input and output paths in seg6 lwtunnelThe seg6 lwtunnel uses a single dst_cache per encap route, sharedbetween seg6_input_core() and seg6_output_core(). These two pathscan perform the post-encap SID lookup in different routing contexts(e.g., ip rules matching on the ingress interface, or VRF tableseparation). Whichever path runs first populates the cache, and theother reuses it blindly, bypassing its own lookup.Fix this by splitting the cache into cache_input and cache_output,so each path maintains its own cached dst independently.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_multiport: validate range encoding in checkentryports_match_v1() treats any non-zero pflags entry as the start of aport range and unconditionally consumes the next ports[] element asthe range end.The checkentry path currently validates protocol, flags and count, butit does not validate the range encoding itself. As a result, malformedrules can mark the last slot as a range start or place two range startsback to back, leaving ports_match_v1() to step past the last validports[] element while interpreting the rule.Reject malformed multiport v1 rules in checkentry by validating thateach range start has a following element and that the following elementis not itself marked as another range start.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/mc: Fix error path ordering in edac_mc_alloc()When the mci->pvt_info allocation in edac_mc_alloc() fails, the error pathwill call put_device() which will end up calling the device's releasefunction.However, the init ordering is wrong such that device_initialize() happens*after* the failed allocation and thus the device itself and the releasefunction pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ...Reorder the calling sequence so that the device is initialized and thus therelease function pointer is properly set before it can be used.This was found by Claude while reviewing another EDAC patch.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:igb: remove napi_synchronize() in igb_down()When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9),the XSK buffer pool is destroyed but NAPI polling continues.igb_clean_rx_irq_zc() repeatedly returns the full budget, preventingnapi_complete_done() from clearing NAPI_STATE_SCHED.igb_down() calls napi_synchronize() before napi_disable() for each queuevector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear,which never happens. igb_down() blocks indefinitely, the TX watchdogfires, and the TX queue remains permanently stalled.napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE.After a full-budget poll, __napi_poll() checks napi_disable_pending(). Ifset, it forces completion and clears NAPI_STATE_SCHED, breaking the loopthat napi_synchronize() cannot.napi_synchronize() was added in commit 41f149a285da ("igb: Fix possiblepanic caused by Rx traffic arrival while interface is down").napi_disable() provides stronger guarantees: it prevents furtherscheduling and waits for any active poll to exit.Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without apreceding napi_synchronize() in their down paths.Remove redundant napi_synchronize() call and reorder napi_disable()before igb_set_queue_napi() so the queue-to-NAPI mapping is onlycleared after polling has fully stopped.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: When libcurl is asked to perform automatic gzip decompression ofcontent-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow wouldmake libcurl perform a buffer overflow.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
curl > 0-0 (version in image is 8.14.1-160000.5.1).
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: add bounds check for if_id in IRQ handlerThe IRQ handler extracts if_id from the upper 16 bits of the hardwarestatus register and uses it to index into ethsw->ports[] withoutvalidation. Since if_id can be any 16-bit value (0-65535) but the portsarray is only allocated with sw_attr.num_ifs elements, this can lead toan out-of-bounds read potentially.Add a bounds check before accessing the array, consistent with theexisting validation in dpaa2_switch_rx().
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zeroThe driver allocates arrays for ports, FDBs, and filter blocks usingkcalloc() with ethsw->sw_attr.num_ifs as the element count. When thedevice reports zero interfaces (either due to hardware configurationor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)instead of NULL.Later in dpaa2_switch_probe(), the NAPI initialization unconditionallyaccesses ethsw->ports[0]->netdev, which attempts to dereferenceZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.Add a check to ensure num_ifs is greater than zero after retrievingdevice attributes. This prevents the zero-sized allocations andsubsequent invalid pointer dereference.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:bridge: br_nd_send: linearize skb before parsing ND optionsbr_nd_send() parses neighbour discovery options from ns->opt[] andassumes that these options are in the linear part of request.Its callers only guarantee that the ICMPv6 header and target addressare available, so the option area can still be non-linear. Parsingns->opt[] in that case can access data past the linear buffer.Linearize request before option parsing and derive ns from the linearnetwork header.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Active Storage allows users to attach cloud and local files in Rails applications. Prior to versions 8.1.2.1, 8.0.4.1, and 7.2.3.1, `DirectUploadsController` accepts arbitrary metadata from the client and persists it on the blob. Because internal flags like `identified` and `analyzed` are stored in the same metadata hash, a direct-upload client can set these flags to skip MIME detection and analysis. This allows an attacker to upload arbitrary content while claiming a safe `content_type`, bypassing any validations that rely on Active Storage's automatic content type identification. Versions 8.1.2.1, 8.0.4.1, and 7.2.3.1 contain a patch.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.3.1).
Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entryEndpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-Xinterrupt to the host using a writel(), which generates a PCI posted writetransaction. There's no completion for posted writes, so the writel() mayreturn before the PCI write completes. dw_pcie_ep_raise_msix_irq() alsounmaps the outbound ATU entry used for the PCI write, so the write raceswith the unmap.If the PCI write loses the race with the ATU unmap, the write may corrupthost memory or cause IOMMU errors, e.g., these when running fio with alarger queue depth against nvmet-pci-epf: arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0Flush the write by performing a readl() of the same address to ensure thatthe write has reached the destination before the ATU entry is unmapped.The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but thereit was solved by dedicating an outbound iATU only for MSI. We can't do thesame for MSI-X because each vector can have a different msg_addr and themsg_addr may be changed while the vector is masked.[bhelgaas: commit log]
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: Multiple uses of uninitialized variables were found in libopensc that may lead to information disclosure or application crash. An attack requires a crafted USB device or smart card that would present the system with specially crafted responses to the APDUs
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
opensc > 0-0 (version in image is 0.26.1-160000.2.2).
Description: OpenSC is an open source smart card tools and middleware. Prior to version 0.27.0, feeding a crafted input to the fuzz_pkcs15_reader harness causes OpenSC to perform an out-of-bounds heap read in the X.509/SPKI handling path. Specifically, sc_pkcs15_pubkey_from_spki_fields() allocates a zero-length buffer and then reads one byte past the end of that allocation. This issue has been patched in version 0.27.0.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
opensc > 0-0 (version in image is 0.26.1-160000.2.2).
Description: OpenSC is an open source smart card tools and middleware. Prior to version 0.27.0, sc_compacttlv_find_tag searches a compact-TLV buffer for a given tag. In compact-TLV, a single byte encodes the tag (high nibble) and value length (low nibble). With a 1-byte buffer {0x0A}, the encoded element claims tag=0 and length=10 but no value bytes follow. Calling sc_compacttlv_find_tag with search tag 0x00 returns a pointer equal to buf+1 and outlen=10 without verifying that the claimed value length fits within the remaining buffer. In cases where the sc_compacttlv_find_tag is provided untrusted data (such as being read from cards/files), attackers may be able to influence it to return out-of-bounds pointers leading to downstream memory corruption when subsequent code tries to dereference the pointer. This issue has been patched in version 0.27.0.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
opensc > 0-0 (version in image is 0.26.1-160000.2.2).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: OpenSC is an open source smart card tools and middleware. Prior to version 0.27.0, an attacker with physical access to the computer at the time user or administrator uses a token can cause a stack-buffer-overflow write in GET RESPONSE. The attack requires crafted USB device or smart card that would present the system with specially crafted responses to the APDUs. This issue has been patched in version 0.27.0.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
opensc > 0-0 (version in image is 0.26.1-160000.2.2).
Description: OpenSC is an open source smart card tools and middleware. Prior to version 0.27.0, an attacker with physical access to the computer at the time user or administrator uses a token can cause a stack-buffer-overflow WRITE in card-oberthur. The attack requires crafted USB device or smart card that would present the system with specially crafted responses to the APDUs. This issue has been patched in version 0.27.0.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
opensc > 0-0 (version in image is 0.26.1-160000.2.2).
Description: http.cookies.Morsel.js_output() returns an inline inside the generated script element. Mitigation base64-encodes the cookie value to disallow escaping using cookie value.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: A flaw was found in libssh in which a malicious SFTP (SSH File Transfer Protocol) server can exploit this by sending a malformed 'longname' field within an `SSH_FXP_NAME` message during a file listing operation. This missing null check can lead to reading beyond allocated memory on the heap. This can cause unexpected behavior or lead to a denial of service (DoS) due to application crashes.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
Description: Libgcrypt before 1.12.2 mishandles Dilithium signing. Writes to a static array lack a bounds check but do not use attacker-controlled data.
Packages affected:
libgcrypt20 > 0-0 (version in image is 1.11.1-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actualuser on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.
Packages affected:
podman > 0-0 (version in image is 5.4.2-160000.4.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to 2.4.17, a network-adjacent attacker can send a crafted SNMP response to the CUPS SNMP backend that causes an out-of-bounds read of up to 176 bytes past a stack buffer. The leaked memory is converted from UTF-16 to UTF-8 and stored as printer supply description strings, which are subsequently visible to authenticated users via IPP Get-Printer-Attributes responses and the CUPS web interface. This vulnerability is fixed in 2.4.17.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
cups-config > 0-0 (version in image is 2.4.16-160000.1.1).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
elfutils > 0-0 (version in image is 0.192-160000.3.1).
Description: PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. In versions 0.6.12 and prior, the pam_pkcs11 module segfaults when a user presses ctrl-c/ctrl-d when they are asked for a PIN. When a user enters no PIN at all, `pam_get_pwd` will never initialize the password buffer pointer and as such `cleanse` will try to dereference an uninitialized pointer. On my system this pointer happens to have the value 3 most of the time when running sudo and as such it will segfault. The most likely impact to a system affected by this issue is an availability impact due to a daemon that uses PAM crashing. As of time of publication, a patch for the issue is unavailable.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
pam_pkcs11 > 0-0 (version in image is 0.6.13-160000.2.2).
Description: The `rsa` crate is an RSA implementation written in rust. Prior to version 0.9.10, when creating a RSA private key from its components, the construction panics instead of returning an error when one of the primes is `1`. Version 0.9.10 fixes the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
himmelblau > 0-0 (version in image is 2.3.8+git0.dec3693-160000.1.1).
Description: pip handles concatenated tar and ZIP files as ZIP files regardless of filename or whether a file is both a tar and ZIP file. This behavior could result in confusing installation behavior, such as installing "incorrect" files according to the filename of the archive. New behavior only proceeds with installation if the file identifies uniquely as a ZIP or tar archive, not as both.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313 > 0-0 (version in image is 3.13.13-160000.1.1).
Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libncurses6 > 0-0 (version in image is 6.5.20250531-160000.2.2).
Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing a manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be used for attacks.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing a manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be used for attacks. This patch is called 16357. It is best practice to apply a patch to resolve this issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: Cairo through 1.18.4, as used in Poppler through 25.08.0, has an "unscaled->face == NULL" assertion failure for _cairo_ft_unscaled_font_fini in cairo-ft-font.c.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libcairo-gobject2 > 0-0 (version in image is 1.18.4-160000.2.2).
Description: Binutils objdump contains a denial-of-service vulnerability when processing a crafted binary with malformed DWARF debug information. A logic error in the handling of DWARF compilation units can result in an invalid offset_size value being used inside byte_get_little_endian, leading to an abort (SIGABRT). The issue was observed in binutils 2.44. A local attacker can trigger the crash by supplying a malicious input file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid chain re-validation if possibleHamza Mahfooz reports cpu soft lock-ups innft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547][..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables][..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables][..]Currently nf_tables will traverse the entire table (chain graph), startingfrom the entry points (base chains), exploring all possible paths(chain jumps). But there are cases where we could avoid revalidation.Consider:1 input -> j2 -> j32 input -> j2 -> j33 input -> j1 -> j2 -> j3Then the second rule does not need to revalidate j2, and, by extension j3,because this was already checked during validation of the first rule.We need to validate it only for rule 3.This is needed because chain loop detection also ensures we do not exceedthe jump stack: Just because we know that j2 is cycle free, its last jumpmight now exceed the allowed stack size. We also need to update allreachable chains with the new largest observed call depth.Care has to be taken to revalidate even if the chain depth won't be anissue: chain validation also ensures that expressions are not called frominvalid base chains. For example, the masquerade expression can only becalled from NAT postrouting base chains.Therefore we also need to keep record of the base chain context (type,hooknum) and revalidate if the chain becomes reachable from a differenthook location.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:audit: add fchmodat2() to change attributes classfchmodat2(), introduced in version 6.6 is currently not in the changeattribute class of audit. Calling fchmodat2() to change a fileattribute in the same fashion than chmod() or fchmodat() will bypassaudit rules such as:-w /tmp/test -p rwa -k test_rwaThe current patch adds fchmodat2() to the change attributes class.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: A flaw was found in libssh where it can attempt to open arbitrary files during configuration parsing. A local attacker can exploit this by providing a malicious configuration file or when the system is misconfigured. This vulnerability could lead to a Denial of Service (DoS) by causing the system to try and access dangerous files, such as block devices or large system files, which can disrupt normal operations.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix kmemleak by releasing references to fault configfs itemsWhen CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blkdriver sets up fault injection support by creating the timeout_inject,requeue_inject, and init_hctx_fault_inject configfs items as childrenof the top-level nullbX configfs group.However, when the nullbX device is removed, the references taken tothese fault-config configfs items are not released. As a result,kmemleak reports a memory leak, for example:unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ecFix this by explicitly releasing the references to the fault-configconfigfs items when dropping the reference to the top-level nullbXconfigfs group.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Initialize netdev pointer before queue setupIn setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq().However, the pointer to this structure is stored in oct->props[i].netdevonly after the calls to netif_set_real_num_rx_queues() andnetif_set_real_num_tx_queues().If either of these functions fails, setup_nic_devices() returns an errorwithout freeing the allocated netdev. Since oct->props[i].netdev is stillNULL at this point, the cleanup function liquidio_destroy_nic_device()will fail to find and free the netdev, resulting in a memory leak.Fix this by initializing oct->props[i].netdev before calling the queuesetup functions. This ensures that the netdev is properly accessible forcleanup in case of errors.Compile tested only. Issue found using a prototype static analysis tooland code review.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK};rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata().The reserved members of the structure were not zeroed.
Packages affected:
cluster-md-kmp-default < 6.12.0-160000.28.1 (version in image is 6.12.0-160000.27.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: clone set on flush onlySyzbot with fault injection triggered a failing memory allocation withGFP_KERNEL which results in a WARN splat:iter.errWARNING: net/netfilter/nf_tables_api.c:845 at nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992Modules linked in:CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026RIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43+80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9RSP: 0018:ffffc900045af780 EFLAGS: 00010293RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffffR10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0Call Trace: __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115 nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380 netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761 __sock_release net/socket.c:662 [inline] sock_close+0xc3/0x240 net/socket.c:1455Restrict set clone to the flush set command in the preparation phase.Add NFT_ITER_UPDATE_CLONE and use it for this purpose, update the rbtreeand pipapo backends to only clone the set when this iteration type isused.As for the existing NFT_ITER_UPDATE type, update the pipapo backend touse the existing set clone if available, otherwise use the existing setrepresentation. After this update, there is no need to clone a set thatis being deleted, this includes bound anonymous set.An alternative approach to NFT_ITER_UPDATE_CLONE is to add a .cloneinterface and call it from the flush set path.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
vim > 0-0 (version in image is 9.2.0280-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_expect: skip expectations in other netns via procSkip expectations that do not reside in this netns.Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns'sconntrack entries via proc").
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:net: lan966x: fix page pool leak in error pathslan966x_fdma_rx_alloc() creates a page pool but does not destroy it ifthe subsequent fdma_alloc_coherent() call fails, leaking the pool.Similarly, lan966x_fdma_init() frees the coherent DMA memory whenlan966x_fdma_tx_alloc() fails but does not destroy the page pool thatwas successfully created by lan966x_fdma_rx_alloc(), leaking it.Add the missing page_pool_destroy() calls in both error paths.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:xfrm_user: fix info leak in build_report()struct xfrm_user_report is a __u8 proto field followed by a structxfrm_selector which means there is three "empty" bytes of padding, butthe padding is never zeroed before copying to userspace. Fix that up byzeroing the structure before setting individual member variables.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid memory leak in f2fs_rename()syzbot reported a f2fs bug as below:BUG: memory leakunreferenced object 0xffff888127f70830 (size 16): comm "syz.0.23", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4520 [inline] slab_alloc_node mm/slub.c:4844 [inline] __do_kmalloc_node mm/slub.c:5237 [inline] __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143 f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961 f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfs_rename+0x7ff/0x1250 fs/namei.c:6026 filename_renameat2+0x4f4/0x660 fs/namei.c:6144 __do_sys_renameat2 fs/namei.c:6173 [inline] __se_sys_renameat2 fs/namei.c:6168 [inline] __x64_sys_renameat2+0x59/0x80 fs/namei.c:6168 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinuxlabel during whiteout initialization"), we added a call tof2fs_setup_filename() without a matching call to f2fs_free_filename(),fix it.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A vulnerability was determined in strukturag libheif up to 1.21.2. This affects the function vvdec_push_data2 of the file libheif/plugins/decoder_vvdec.cc of the component HEIF File Parser. Executing a manipulation of the argument size can lead to out-of-bounds read. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. This patch is called b97c8b5f198b27f375127cd597a35f2113544d03. It is advisable to implement a patch to correct this issue.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libheif1 > 0-0 (version in image is 1.19.7-160000.3.1).
Description: A security flaw has been discovered in pygments up to 2.19.2. The impacted element is the function AdlLexer of the file pygments/lexers/archetype.py. The manipulation results in inefficient regular expression complexity. The attack is only possible with local access. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
python313-Pygments > 0-0 (version in image is 2.19.1-160000.2.2).
Description: A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
cockpit > 0-0 (version in image is 354-160000.3.1).
Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
elfutils > 0-0 (version in image is 0.192-160000.3.1).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
elfutils > 0-0 (version in image is 0.192-160000.3.1).
Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
cockpit > 0-0 (version in image is 354-160000.3.1).
Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
binutils > 0-0 (version in image is 2.45-160000.1.1).
Description: In the Linux kernel, the following vulnerability has been resolved:s390/entry: Scrub r12 register on kernel entryBefore commit f33f2d4c7c80 ("s390/bp: remove TIF_ISOLATE_BP"),all entry handlers loaded r12 with the current task pointer(lg %r12,__LC_CURRENT) for use by the BPENTER/BPEXIT macros. Thatcommit removed TIF_ISOLATE_BP, dropping both the branch predictionmacros and the r12 load, but did not add r12 to the register clearingsequence.Add the missing xgr %r12,%r12 to make the register scrub consistentacross all entry points.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.27.1).
Description: A flaw was found in libssh. A remote attacker, by controlling client configuration files or known_hosts files, could craft specific hostnames that when processed by the `match_pattern()` function can lead to inefficient regular expression backtracking. This can cause timeouts and resource exhaustion, resulting in a Denial of Service (DoS) for the client.
Packages affected:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
libssh-config < 0.11.4-160000.1.1 (version in image is 0.11.2-160000.2.2).
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:
SLES_SAP-release == 16.0 (version in image is 16.0-160000.43.1).
elfutils > 0-0 (version in image is 0.192-160000.3.1).