An update for kernel is now available for openEuler-24.03-LTS-SP1 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2766 Final 1.0 1.0 2025-11-28 Initial 2025-11-28 2025-11-28 openEuler SA Tool V1.0 2025-11-28 kernel security update An update for kernel is now available for openEuler-24.03-LTS-SP1 The Linux Kernel, the operating system core itself. Security Fix(es): A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357) In the Linux kernel, the following vulnerability has been resolved: cdx: Fix possible UAF error in driver_override_show() Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c This function driver_override_show() is part of DEVICE_ATTR_RW, which includes both driver_override_show() and driver_override_store(). These functions can be executed concurrently in sysfs. The driver_override_store() function uses driver_set_override() to update the driver_override value, and driver_set_override() internally locks the device (device_lock(dev)). If driver_override_show() reads cdx_dev->driver_override without locking, it could potentially access a freed pointer if driver_override_store() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users. Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations.(CVE-2025-21915) In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Prevent integer overflow in hdr_first_de() The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow.(CVE-2025-22080) In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one error in do_split Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150) In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785) In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort() A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed. This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). This is found by our static analysis tool KNighter.(CVE-2025-37828) In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [(CVE-2025-38084) In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.(CVE-2025-38100) In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0.(CVE-2025-38173) In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38214) In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix crash when rebind ccp device for ccp.ko When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X.(CVE-2025-38581) In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix null pointer access Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705) In the Linux kernel, the following vulnerability has been resolved: net: kcm: Fix race condition in kcm_unattach() syzbot found a race condition when kcm_unattach(psock) and kcm_release(kcm) are executed at the same time. kcm_unattach() is missing a check of the flag kcm->tx_stopped before calling queue_work(). If the kcm has a reserved psock, kcm_unattach() might get executed between cancel_work_sync() and unreserve_psock() in kcm_release(), requeuing kcm->tx_work right before kcm gets freed in kcm_done(). Remove kcm->tx_stopped and replace it by the less error-prone disable_work_sync().(CVE-2025-38717) In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 power domain descriptors, too UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729) In the Linux kernel, the following vulnerability has been resolved: smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy() We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()! Otherwise already existing connections try to use smb_direct_wq as a NULL pointer.(CVE-2025-39692) In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix SCCB present check Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation. If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. Fix this by introducing a function that handles the NULL case before address translation.(CVE-2025-39694) In the Linux kernel, the following vulnerability has been resolved: net, hsr: reject HSR frame if skb can't hold tag Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG): [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 <snip registers, remove unreliable trace> [ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ> This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics. The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG). Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers. Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network. Further Details: In the reproducer, the following network interface chain is set up: ┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---(CVE-2025-39703) Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39751) In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.(CVE-2025-39931) In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0(CVE-2025-39938) In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;(CVE-2025-39940) In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.(CVE-2025-39964) In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.(CVE-2025-39992) In the Linux kernel, the following vulnerability has been resolved: net/smc: fix warning in smc_rx_splice() when calling get_page() smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are later passed to get_page() in smc_rx_splice(). Since kmalloc memory is not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents holding a refcount on the buffer. This can lead to use-after-free if the memory is released before splice_to_pipe() completes. Use folio_alloc() instead, ensuring DMBs are page-backed and safe for get_page(). WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc] CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE Hardware name: IBM 3931 A01 704 (z/VM 7.4.0) Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8 Krnl Code: 0007931610326960: af000000 mc 0,0 0007931610326964: a7f4ff43 brc 15,00079316103267ea #0007931610326968: af000000 mc 0,0 >000793161032696c: a7f4ff3f brc 15,00079316103267ea 0007931610326970: e320f1000004 lg %r2,256(%r15) 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560 000793161032697c: a7f4fbb5 brc 15,00079316103260e6 0007931610326980: b904002b lgr %r2,%r11 Call Trace: smc_rx_splice+0xafc/0xe20 [smc] smc_rx_splice+0x756/0xe20 [smc]) smc_rx_recvmsg+0xa74/0xe00 [smc] smc_splice_read+0x1ce/0x3b0 [smc] sock_splice_read+0xa2/0xf0 do_splice_read+0x198/0x240 splice_file_to_pipe+0x7e/0x110 do_splice+0x59e/0xde0 __do_splice+0x11a/0x2d0 __s390x_sys_splice+0x140/0x1f0 __do_syscall+0x122/0x280 system_call+0x6e/0x90 Last Breaking-Event-Address: smc_rx_splice+0x960/0xe20 [smc] ---[ end trace 0000000000000000 ]---(CVE-2025-40012) In the Linux kernel, the following vulnerability has been resolved: Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace. Initialize ff_up_compat to zero before filling valid fields.(CVE-2025-40035) In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Add parameter validation for packet data Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools"). This bug arises due to very limited and poor input validation that was done at nic_valid_size(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of `skb_buff->data` which is not assigned anything yet. Following the same silent drop of packets of invalid sizes at `nic_valid_size()`, add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in `nci_nft_packet` and effectively do a silent drop Possible TODO: because we silently drop the packets, the call to `nci_request` will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export `nci_request_cancel` (or propagate error handling from the nft packets handlers).(CVE-2025-40043) In the Linux kernel, a race condition vulnerability exists in the uio_hv_generic driver. The driver's default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang. Specifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there's already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely. The fix removes all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX.(CVE-2025-40048) In the Linux kernel, the following vulnerability has been resolved: net: dlink: handle copy_thresh allocation failure The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference. This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path. Tested-on: D-Link DGE-550T Rev-A3(CVE-2025-40053) In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix double free in user_cluster_connect() user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free.(CVE-2025-40055) In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290 CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 </TASK> Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f When hfsplus_uni2asc is called from hfsplus_listxattr, it actually passes in a struct hfsplus_attr_unistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory. This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str to process two unicode buffers, struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size.(CVE-2025-40082) In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read.(CVE-2025-40084) In the Linux kernel, a buffer overflow vulnerability exists in the hfsplus_strcasecmp() function of the hfsplus filesystem. When the hfsplus_strcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks.(CVE-2025-40088) In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present. Ensure that set_ent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue.(CVE-2025-40109) In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean "no surface", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code.(CVE-2025-40110) In the Linux kernel, the following vulnerability has been resolved: net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock Prevent USB runtime PM (autosuspend) for AX88772* in bind. usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend. The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues. To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides. Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before.(CVE-2025-40120) In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue.(CVE-2025-40123) In the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blk_mq_sysfs_register_hctxs() is not checked in __blk_mq_update_nr_hw_queues() function. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger kernel warnings. The issue occurs because kobject_del() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors.(CVE-2025-40125) In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix null pointer dereference on zero-length checksum In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT.(CVE-2025-40129) In the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q->tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2.(CVE-2025-40134) In the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver's rtl8150_set_multicast function. The vulnerability occurs because rtl8150_set_multicast incorrectly calls netif_stop_queue and netif_wake_queue, causing TX queue synchronization issues. When rtl8150_set_multicast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150_start_xmit, resulting in warnings and potential system instability.(CVE-2025-40140) In the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in sco_conn_free where if conn->sk is not set to NULL, it may lead to use-after-free in iso_conn_free.(CVE-2025-40141) A vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup.(CVE-2025-40153) In the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smp_processor_id() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smp_processor_id() function in the usbnet_skb_return function within preemptible context.(CVE-2025-40164) In the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUG_ON in ext4_es_cache_extent(). The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINE_DATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes.(CVE-2025-40167) In the Linux kernel, the check_alu_op() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the 'offset' field is a signed 16-bit integer. The original check condition 'insn->off > 1' was intended to ensure the offset is either 0 or 1 (for BPF_MOD/BPF_DIV operations). However, since 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues.(CVE-2025-40169) In the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from __nvmet_fc_send_ls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches.(CVE-2025-40171) In the Linux kernel, a vulnerability has been identified in the net/ip6_tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev->needed_headroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks.(CVE-2025-40173) In the Linux kernel, during asynchronous decryption in the TLS module, the tls_strp_msg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete.(CVE-2025-40176) In the Linux kernel, there is a NULL pointer dereference vulnerability in the pid_nr_ns function. When task_active_pid_ns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when task_active_pid_ns returns null in the pid_nr_ns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is 'Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058', ultimately causing kernel panic and system crash.(CVE-2025-40178) In the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files.(CVE-2025-40179) In the Linux kernel, a memory leak vulnerability exists. Cilium's BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpf_redirect_neigh() helper to forward packets, vxlan allocates metadata_dst objects and attaches them to skb through fake dst entries. However, since bpf_redirect_neigh() only sets new dst entries without first dropping existing ones, the metadata_dst objects are never released, causing continuous increase in kmalloc-256 slab usage.(CVE-2025-40183) In the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0, and sctp_ulpevent_make_authkey() returns 0, the variable ai_ev remains zero and this zero value will be dereferenced in the sctp_ulpevent_free() function.(CVE-2025-40187) In the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: ea_inode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount.(CVE-2025-40190) In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected". This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.(CVE-2025-40192) In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request(). The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.(CVE-2025-40194) In the Linux kernel, a buffer over-read vulnerability has been discovered in the parse_apply_sb_mount_options() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure s_mount_opts is NUL terminated. The parse_apply_sb_mount_options() function has been hardened by treating s_mount_opts as a potential __nonstring.(CVE-2025-40198) In the Linux kernel, a vulnerability has been identified in the Squashfs filesystem's squashfs_read_inode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL.(CVE-2025-40200) In the Linux kernel, the sys_prlimit64() path has a race condition issue with the usage of task_lock(tsk->group_leader). When tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). The fix changes sys_prlimit64() to take tasklist_lock when necessary.(CVE-2025-40201) In the Linux kernel, the IPMI subsystem's user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1.(CVE-2025-40202) In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204) In the Linux kernel, the netfilter nft_objref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFT_OBJECT_SYNPROXY object type requires validation.(CVE-2025-40206) In the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switch_brightness_work delayed work accesses device->brightness and device->backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. The issue is fixed by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed.(CVE-2025-40211) An update for kernel is now available for openEuler-24.03-LTS-SP1. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36357 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-21915 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-22080 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-23150 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37785 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-37828 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38084 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38100 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38173 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38214 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38581 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38705 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38717 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38729 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39692 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39694 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39703 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39751 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39931 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39938 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39940 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39964 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39992 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40012 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40035 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40043 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40048 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40053 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40055 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40082 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40084 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40088 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40109 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40110 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40120 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40123 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40125 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40129 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40134 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40140 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40141 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40153 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40164 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40167 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40169 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40171 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40173 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40176 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40178 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40179 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40183 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40187 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40190 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40192 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40194 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40198 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40200 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40201 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40202 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40204 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40206 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-40211 https://nvd.nist.gov/vuln/detail/CVE-2024-36357 https://nvd.nist.gov/vuln/detail/CVE-2025-21915 https://nvd.nist.gov/vuln/detail/CVE-2025-22080 https://nvd.nist.gov/vuln/detail/CVE-2025-23150 https://nvd.nist.gov/vuln/detail/CVE-2025-37785 https://nvd.nist.gov/vuln/detail/CVE-2025-37828 https://nvd.nist.gov/vuln/detail/CVE-2025-38084 https://nvd.nist.gov/vuln/detail/CVE-2025-38100 https://nvd.nist.gov/vuln/detail/CVE-2025-38173 https://nvd.nist.gov/vuln/detail/CVE-2025-38214 https://nvd.nist.gov/vuln/detail/CVE-2025-38581 https://nvd.nist.gov/vuln/detail/CVE-2025-38705 https://nvd.nist.gov/vuln/detail/CVE-2025-38717 https://nvd.nist.gov/vuln/detail/CVE-2025-38729 https://nvd.nist.gov/vuln/detail/CVE-2025-39692 https://nvd.nist.gov/vuln/detail/CVE-2025-39694 https://nvd.nist.gov/vuln/detail/CVE-2025-39703 https://nvd.nist.gov/vuln/detail/CVE-2025-39751 https://nvd.nist.gov/vuln/detail/CVE-2025-39931 https://nvd.nist.gov/vuln/detail/CVE-2025-39938 https://nvd.nist.gov/vuln/detail/CVE-2025-39940 https://nvd.nist.gov/vuln/detail/CVE-2025-39964 https://nvd.nist.gov/vuln/detail/CVE-2025-39992 https://nvd.nist.gov/vuln/detail/CVE-2025-40012 https://nvd.nist.gov/vuln/detail/CVE-2025-40035 https://nvd.nist.gov/vuln/detail/CVE-2025-40043 https://nvd.nist.gov/vuln/detail/CVE-2025-40048 https://nvd.nist.gov/vuln/detail/CVE-2025-40053 https://nvd.nist.gov/vuln/detail/CVE-2025-40055 https://nvd.nist.gov/vuln/detail/CVE-2025-40082 https://nvd.nist.gov/vuln/detail/CVE-2025-40084 https://nvd.nist.gov/vuln/detail/CVE-2025-40088 https://nvd.nist.gov/vuln/detail/CVE-2025-40109 https://nvd.nist.gov/vuln/detail/CVE-2025-40110 https://nvd.nist.gov/vuln/detail/CVE-2025-40120 https://nvd.nist.gov/vuln/detail/CVE-2025-40123 https://nvd.nist.gov/vuln/detail/CVE-2025-40125 https://nvd.nist.gov/vuln/detail/CVE-2025-40129 https://nvd.nist.gov/vuln/detail/CVE-2025-40134 https://nvd.nist.gov/vuln/detail/CVE-2025-40140 https://nvd.nist.gov/vuln/detail/CVE-2025-40141 https://nvd.nist.gov/vuln/detail/CVE-2025-40153 https://nvd.nist.gov/vuln/detail/CVE-2025-40164 https://nvd.nist.gov/vuln/detail/CVE-2025-40167 https://nvd.nist.gov/vuln/detail/CVE-2025-40169 https://nvd.nist.gov/vuln/detail/CVE-2025-40171 https://nvd.nist.gov/vuln/detail/CVE-2025-40173 https://nvd.nist.gov/vuln/detail/CVE-2025-40176 https://nvd.nist.gov/vuln/detail/CVE-2025-40178 https://nvd.nist.gov/vuln/detail/CVE-2025-40179 https://nvd.nist.gov/vuln/detail/CVE-2025-40183 https://nvd.nist.gov/vuln/detail/CVE-2025-40187 https://nvd.nist.gov/vuln/detail/CVE-2025-40190 https://nvd.nist.gov/vuln/detail/CVE-2025-40192 https://nvd.nist.gov/vuln/detail/CVE-2025-40194 https://nvd.nist.gov/vuln/detail/CVE-2025-40198 https://nvd.nist.gov/vuln/detail/CVE-2025-40200 https://nvd.nist.gov/vuln/detail/CVE-2025-40201 https://nvd.nist.gov/vuln/detail/CVE-2025-40202 https://nvd.nist.gov/vuln/detail/CVE-2025-40204 https://nvd.nist.gov/vuln/detail/CVE-2025-40206 https://nvd.nist.gov/vuln/detail/CVE-2025-40211 openEuler-24.03-LTS-SP1 bpftool-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm bpftool-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-debugsource-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-devel-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-headers-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-source-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-tools-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-tools-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-tools-devel-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm perf-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm python3-perf-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm python3-perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm kernel-6.6.0-121.0.0.123.oe2403sp1.src.rpm bpftool-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm bpftool-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-debugsource-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-devel-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-headers-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-source-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-tools-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-tools-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm kernel-tools-devel-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm perf-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm python3-perf-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm python3-perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries. 2025-11-28 CVE-2024-36357 openEuler-24.03-LTS-SP1 Medium 5.6 AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: cdx: Fix possible UAF error in driver_override_show() Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c This function driver_override_show() is part of DEVICE_ATTR_RW, which includes both driver_override_show() and driver_override_store(). These functions can be executed concurrently in sysfs. The driver_override_store() function uses driver_set_override() to update the driver_override value, and driver_set_override() internally locks the device (device_lock(dev)). If driver_override_show() reads cdx_dev->driver_override without locking, it could potentially access a freed pointer if driver_override_store() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users. Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. 2025-11-28 CVE-2025-21915 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Prevent integer overflow in hdr_first_de() The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow. 2025-11-28 CVE-2025-22080 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one error in do_split Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. 2025-11-28 CVE-2025-23150 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e 2025-11-28 CVE-2025-37785 openEuler-24.03-LTS-SP1 High 7.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort() A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed. This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). This is found by our static analysis tool KNighter. 2025-11-28 CVE-2025-37828 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [ 2025-11-28 CVE-2025-38084 openEuler-24.03-LTS-SP1 High 7.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state. 2025-11-28 CVE-2025-38100 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0. 2025-11-28 CVE-2025-38173 openEuler-24.03-LTS-SP1 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. 2025-11-28 CVE-2025-38214 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix crash when rebind ccp device for ccp.ko When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X. 2025-11-28 CVE-2025-38581 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix null pointer access Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference. 2025-11-28 CVE-2025-38705 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:H/UI:R/S:C/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: net: kcm: Fix race condition in kcm_unattach() syzbot found a race condition when kcm_unattach(psock) and kcm_release(kcm) are executed at the same time. kcm_unattach() is missing a check of the flag kcm->tx_stopped before calling queue_work(). If the kcm has a reserved psock, kcm_unattach() might get executed between cancel_work_sync() and unreserve_psock() in kcm_release(), requeuing kcm->tx_work right before kcm gets freed in kcm_done(). Remove kcm->tx_stopped and replace it by the less error-prone disable_work_sync(). 2025-11-28 CVE-2025-38717 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 power domain descriptors, too UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too. 2025-11-28 CVE-2025-38729 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy() We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()! Otherwise already existing connections try to use smb_direct_wq as a NULL pointer. 2025-11-28 CVE-2025-39692 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix SCCB present check Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation. If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping. Fix this by introducing a function that handles the NULL case before address translation. 2025-11-28 CVE-2025-39694 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: net, hsr: reject HSR frame if skb can't hold tag Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG): [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0 <snip registers, remove unreliable trace> [ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ> This issue was found by syzkaller. The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics. The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG). Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers. Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit(). In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network. Further Details: In the reproducer, the following network interface chain is set up: ┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘ To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated--- 2025-11-28 CVE-2025-39703 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. 2025-11-28 CVE-2025-39751 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop. 2025-11-28 CVE-2025-39931 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0 2025-11-28 CVE-2025-39938 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt; 2025-11-28 CVE-2025-39940 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing. 2025-11-28 CVE-2025-39964 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue. 2025-11-28 CVE-2025-39992 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: net/smc: fix warning in smc_rx_splice() when calling get_page() smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are later passed to get_page() in smc_rx_splice(). Since kmalloc memory is not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents holding a refcount on the buffer. This can lead to use-after-free if the memory is released before splice_to_pipe() completes. Use folio_alloc() instead, ensuring DMBs are page-backed and safe for get_page(). WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc] CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE Hardware name: IBM 3931 A01 704 (z/VM 7.4.0) Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8 Krnl Code: 0007931610326960: af000000 mc 0,0 0007931610326964: a7f4ff43 brc 15,00079316103267ea #0007931610326968: af000000 mc 0,0 >000793161032696c: a7f4ff3f brc 15,00079316103267ea 0007931610326970: e320f1000004 lg %r2,256(%r15) 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560 000793161032697c: a7f4fbb5 brc 15,00079316103260e6 0007931610326980: b904002b lgr %r2,%r11 Call Trace: smc_rx_splice+0xafc/0xe20 [smc] smc_rx_splice+0x756/0xe20 [smc]) smc_rx_recvmsg+0xa74/0xe00 [smc] smc_splice_read+0x1ce/0x3b0 [smc] sock_splice_read+0xa2/0xf0 do_splice_read+0x198/0x240 splice_file_to_pipe+0x7e/0x110 do_splice+0x59e/0xde0 __do_splice+0x11a/0x2d0 __s390x_sys_splice+0x140/0x1f0 __do_syscall+0x122/0x280 system_call+0x6e/0x90 Last Breaking-Event-Address: smc_rx_splice+0x960/0xe20 [smc] ---[ end trace 0000000000000000 ]--- 2025-11-28 CVE-2025-40012 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace. Initialize ff_up_compat to zero before filling valid fields. 2025-11-28 CVE-2025-40035 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Add parameter validation for packet data Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools"). This bug arises due to very limited and poor input validation that was done at nic_valid_size(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of `skb_buff->data` which is not assigned anything yet. Following the same silent drop of packets of invalid sizes at `nic_valid_size()`, add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in `nci_nft_packet` and effectively do a silent drop Possible TODO: because we silently drop the packets, the call to `nci_request` will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export `nci_request_cancel` (or propagate error handling from the nft packets handlers). 2025-11-28 CVE-2025-40043 openEuler-24.03-LTS-SP1 Medium 6.3 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a race condition vulnerability exists in the uio_hv_generic driver. The driver's default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang. Specifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there's already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely. The fix removes all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX. 2025-11-28 CVE-2025-40048 openEuler-24.03-LTS-SP1 Medium 6.2 AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: net: dlink: handle copy_thresh allocation failure The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference. This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path. Tested-on: D-Link DGE-550T Rev-A3 2025-11-28 CVE-2025-40053 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix double free in user_cluster_connect() user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free. 2025-11-28 CVE-2025-40055 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290 CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 </TASK> Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f When hfsplus_uni2asc is called from hfsplus_listxattr, it actually passes in a struct hfsplus_attr_unistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory. This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str to process two unicode buffers, struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size. 2025-11-28 CVE-2025-40082 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read. 2025-11-28 CVE-2025-40084 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a buffer overflow vulnerability exists in the hfsplus_strcasecmp() function of the hfsplus filesystem. When the hfsplus_strcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks. 2025-11-28 CVE-2025-40088 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present. Ensure that set_ent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue. 2025-11-28 CVE-2025-40109 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean "no surface", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code. 2025-11-28 CVE-2025-40110 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock Prevent USB runtime PM (autosuspend) for AX88772* in bind. usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend. The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues. To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides. Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before. 2025-11-28 CVE-2025-40120 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce expected_attach_type for tailcall compatibility Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue. 2025-11-28 CVE-2025-40123 openEuler-24.03-LTS-SP1 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blk_mq_sysfs_register_hctxs() is not checked in __blk_mq_update_nr_hw_queues() function. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger kernel warnings. The issue occurs because kobject_del() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors. 2025-11-28 CVE-2025-40125 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix null pointer dereference on zero-length checksum In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT. 2025-11-28 CVE-2025-40129 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q->tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2. 2025-11-28 CVE-2025-40134 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver's rtl8150_set_multicast function. The vulnerability occurs because rtl8150_set_multicast incorrectly calls netif_stop_queue and netif_wake_queue, causing TX queue synchronization issues. When rtl8150_set_multicast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150_start_xmit, resulting in warnings and potential system instability. 2025-11-28 CVE-2025-40140 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in sco_conn_free where if conn->sk is not set to NULL, it may lead to use-after-free in iso_conn_free. 2025-11-28 CVE-2025-40141 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 A vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup. 2025-11-28 CVE-2025-40153 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smp_processor_id() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smp_processor_id() function in the usbnet_skb_return function within preemptible context. 2025-11-28 CVE-2025-40164 openEuler-24.03-LTS-SP1 Low 2.3 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUG_ON in ext4_es_cache_extent(). The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINE_DATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. 2025-11-28 CVE-2025-40167 openEuler-24.03-LTS-SP1 Medium 5.8 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the check_alu_op() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the 'offset' field is a signed 16-bit integer. The original check condition 'insn->off > 1' was intended to ensure the offset is either 0 or 1 (for BPF_MOD/BPF_DIV operations). However, since 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues. 2025-11-28 CVE-2025-40169 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from __nvmet_fc_send_ls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches. 2025-11-28 CVE-2025-40171 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a vulnerability has been identified in the net/ip6_tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev->needed_headroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks. 2025-11-28 CVE-2025-40173 openEuler-24.03-LTS-SP1 Medium 4.1 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, during asynchronous decryption in the TLS module, the tls_strp_msg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete. 2025-11-28 CVE-2025-40176 openEuler-24.03-LTS-SP1 High 7.3 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, there is a NULL pointer dereference vulnerability in the pid_nr_ns function. When task_active_pid_ns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when task_active_pid_ns returns null in the pid_nr_ns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is 'Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058', ultimately causing kernel panic and system crash. 2025-11-28 CVE-2025-40178 openEuler-24.03-LTS-SP1 Medium 5.1 AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files. 2025-11-28 CVE-2025-40179 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a memory leak vulnerability exists. Cilium's BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpf_redirect_neigh() helper to forward packets, vxlan allocates metadata_dst objects and attaches them to skb through fake dst entries. However, since bpf_redirect_neigh() only sets new dst entries without first dropping existing ones, the metadata_dst objects are never released, causing continuous increase in kmalloc-256 slab usage. 2025-11-28 CVE-2025-40183 openEuler-24.03-LTS-SP1 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0, and sctp_ulpevent_make_authkey() returns 0, the variable ai_ev remains zero and this zero value will be dereferenced in the sctp_ulpevent_free() function. 2025-11-28 CVE-2025-40187 openEuler-24.03-LTS-SP1 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: ea_inode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount. 2025-11-28 CVE-2025-40190 openEuler-24.03-LTS-SP1 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected". This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this. 2025-11-28 CVE-2025-40192 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request(). The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later. 2025-11-28 CVE-2025-40194 openEuler-24.03-LTS-SP1 Medium 5.8 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a buffer over-read vulnerability has been discovered in the parse_apply_sb_mount_options() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure s_mount_opts is NUL terminated. The parse_apply_sb_mount_options() function has been hardened by treating s_mount_opts as a potential __nonstring. 2025-11-28 CVE-2025-40198 openEuler-24.03-LTS-SP1 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a vulnerability has been identified in the Squashfs filesystem's squashfs_read_inode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL. 2025-11-28 CVE-2025-40200 openEuler-24.03-LTS-SP1 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the sys_prlimit64() path has a race condition issue with the usage of task_lock(tsk->group_leader). When tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). The fix changes sys_prlimit64() to take tasklist_lock when necessary. 2025-11-28 CVE-2025-40201 openEuler-24.03-LTS-SP1 Medium 5.8 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the IPMI subsystem's user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1. 2025-11-28 CVE-2025-40202 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks. 2025-11-28 CVE-2025-40204 openEuler-24.03-LTS-SP1 Medium 5.3 AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, the netfilter nft_objref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFT_OBJECT_SYNPROXY object type requires validation. 2025-11-28 CVE-2025-40206 openEuler-24.03-LTS-SP1 Medium 4.4 AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766 In the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switch_brightness_work delayed work accesses device->brightness and device->backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. The issue is fixed by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed. 2025-11-28 CVE-2025-40211 openEuler-24.03-LTS-SP1 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-11-28 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766